Readability

I am a firm believer of making code readable.

Readable code helps everyone, including the person who wrote it, to get into the code. Makes it easier to understand the logic, easier to fix bugs when you need to, and easier to re-factor if necessary.

There are basically two approaches:

• Make it readable to everyone - by making it as simple as possible and as close as possible to English.
• Make it follow a project convention.

You can see that the first option is a specific case of the second. Only the convention is very low level, with the attempt to target as many people as possible.

Up until now I always practiced the first option. Both in the companies i worked for and in my personal projects. And was confident that this is the correct route to go by. Right now i am in a company where i need to learn the convention used by the company. And this forced me to rethink my approach.

When I look at large projects, they all develop their own convention. Even if the developers strive to keep the code readable to everyone. The introduction of library functions, utilities, custom markup tags… all generates a new convention, one that is project specific. Anyone who try to get into a large project, have to understand enough of those project specific building blocks in order to be productive.

On the other hand, right now I have to face one of the steepest learning curves i have ever had to climb due to this project specific convention that I have to get used to.

In my case the major thing i have to get used to is condensed code. No spacing, no unnecessary characters, no comments, no empty lines. And did i say it before: no spaces. even between sections of code that have different roles.

Comparing apples and oranges

When you compare the two approaches you get the following table:

Lets look at each factor.

Audience

For projects that target wide audience. Educational projects, open source project, the wider the audience who can read the code, the better. For closed in house projects, the company really care only that the people inside the company will be able to easily get into the code, so it becomes a non-issue for them. Unless they have plans to open the code up in the future.

Learning curve

This is a clear cut. In every project, people change and new people need to come in. The steeper the learning curve is, the harder it is to get new people into it.

Code size

This is another clear cut. Smaller code means less bugs, and less to read and understand.

Conclusion

The bottom line is that whatever you will go by, you will make a compromise. Just make the right compromise for the project you are working on.

New job

Started a new job yesterday. I am back in the position of learning from scratch.

This new company has a strong emphasis on the organizational culture:

• How to write the code
• How to get a task
• How to work on it
• How to report it
• How to email
• How to communicate

And more…

I can tell from the tools and the code base that the company has roots deep into the C/C++ Eco system, despite the work itself being in JavaScript. This means different tools and mindset then in most other JavaScript places I encountered.

Something I’ll have to get used too.

Commute time

But the mind boggling thing to me is the commute time.

2.5 hours for each direction. 5 hours a day. Half a day goes for every workday.

Yes I know it before I took the job, but knowing is not the same as feeling. Yesterday was the first day in a long while where I haven’t seen any of my kids awake at all. I left before they woke up, and came back after they already fall asleep. Why this morning I left only after I saw them leaving for their day.

Transportation

I rolled out a car since for it will be Russian Roulette with almost fully loaded gun.

I know I will fall asleep on the wheel. The only questions are when it will happen, and how badly I’ll be hurt.

This leaves public transportation, that is less then friendly.

Current rout

• Home to bus station - same as with my previous work, mostly by car when my wife drop off the kids.

• Bus to the train station - same as with the previous work. Sadly the bus usually arrive just as the train leaves so I have to wait for the next one.

• Train to a more central station,where I’ll wait for the train that will get me to work

• Train to train station closest to work

• bus or shuttle to work

And the ride home is the same in reverse.

I just realized I forgot to measure the times for each segment. I’ll do it in the next few days and report it.

Mitigations

There are mitigating factors.

I can start the work on the train. Most days there is enough space to work. I have the laptop with everything I need on it. I just need to organize it, something I plan to do this week.

This should give about 90 min of offline work in each direction.

Future

I plan to improve the first and last parts by moving back to the bike.

A new train station is planned closer to my work that will eliminate one step from this route.

The real mitigator is, working from home. I do not plan on working totally from home, history thought me thus is problematic for me, but a few days a week will be great.

Rewrite

I am rewriting this post, more annoyed then I was when I first wrote it, since I lost it over network issue along the way. Mobile is not a good enough tool, yet.

A way to kill time

fill the void in between

Keeps my mind tuned in

Like leaving the engine running

In a getaway car

Does not get you anywhere

But gets you there faster

I decided to revive the separation between posts and ideas in their different stages.

The first step was defining the seeds and half-baked categories, this I just did.

The next step will be to make it more visible, and remove the seeds from the main page.