Hacker News new | past | comments | ask | show | jobs | submit login

There’s another way out of this problem, but you have to focus on making the code dead obvious and simplify the tools for working with it.

That work doesn’t just pay off in rampup time. True, people can figure things out quicker. It’s easier for early career developers to transition to senior positions. It’s less likely for someone to vastly overrun estimates for tricky new features when the code is well factored. But it’s also about scaling your company up.

When your company gets bigger, you will have more than one project. You need to be able to remove people from project A without killing it, and occasionally bring people back to project A at a later date.

These things have been a constant source of drama everywhere I’ve worked where there “wasn’t enough time” to follow my recommendations. The projects grind to a halt and eventually they lose so many of the old people they have to start over. But it’s the same management style so the process repeats.




This works better for established companies than startups, once they know the pain of the first option. However, when on a 6 month runway, it may not be rational to optimize for 6 years, when you aren’t even guaranteed product/market fit.

I specialize in long life software, so I agree with you, but I understand the alternative.


> I specialize in long life software

How does one market themselves in this specialization?


I'd look at Corgibytes as an example - it's not how I market myself as much as what problems I gravitate toward, with the alternative being startups.


Do you have any more details on your recommendations?


Get variable and method/function names right. They matter more than most comments. I remember a code base I inherited

    if avail > 0:
I could never reason well about that. Then I changed it to

    if available_hosts > 0:
and eventually into

    if number_of_hosts_to_scan > 0:
Technically this would be enough

    if number_of_hosts_to_scan:
but it's less clear.

I'm not afraid to type long variable names because the editor has autocomplete. I don't type much and I don't make typos.


If the function is called scan_hosts, then if the parameter is n, it's more or less obvious to me that n it's number of hosts to scan. I'm willing to read a block comment to remind me what n is.


Some issues could be:

1. It is not obvious to everyone. 2. Another integral parameter called k is added later on. Now which is which? 3. Another guy might call all his integral parameters k. n and k are used for the same thing all over the code-base. An outsider might initially think they are different. 4. Names which are descriptive of their use are obvious to everyone by definition.


It may not be obvious to strictly everyone, but that should be reasonably obvious to anyone with enough context to have any business touching that code.


nHosts according to a popular naming standard and using camel case.


At least one of them will be something similar to: write boring code. Document just a little more than you think you need to (be that in self-descriptive variables or actual comments). Don't get fancy unless actual measured performance dictates it, and when you do so, make sure you document both the why (which test indicated this was necessary) and the how (this is what we did, exactly, to make it perform better).


Write code like you’ll have to debug it at 2 am. Some day you will.


Uncle Bob’s Clean Code.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: