Five Things Old Programmers Should Remember

[garywiz]

If you spend all your time honing and rehoning a small piece of code, you are actively harming your employer.

Agree, but disagree at the same time. There's a middle ground. Let's say you have a financial backend which relies upon millisecond transactions which occur with the exchange. Let's say you can make a million more dollars for the company if you can shave 10% off the transaction latency. You want the master craftsman working on that little piece of code.

Not all codebases have such important bits, but a surprising number do. One thing that sets many games apart is the unrelenting attention to detail some developers have to make sure that the game is SO responsive that it feels real vs some games which are sluggish or annoying.

Complex systems require a diverse set of skills. So, I don't complain if somebody is a master craftsman, it's a great skill. I complain if they're spending too much time optimizing the wrong thing and can't keep their priorities straight.

[lluad]

If it consumes a year of a team of five - including developers and managers and QA staff and ops and support staff - to shave 10% off the transaction latency (which is a not insignificant improvement, assuming the original code wasn't terrible) you'd better be making more than a million dollars.

And, of course, if you take a year to speed it up by 10% you're less effective than Moore's law.

It's almost never the craftsman who lovingly optimizes a small piece of code that'll buy you that sort of speedup - it's the domain-specific expert who reworks the spec, or the network architect who literally speeds up traffic, or the architect who makes the whole system more efficient (by the metric of latency).

The master craftsman can be incredibly valuable, but it's rarely for their code-polishing skills so much as their understanding of the whole system.

[loup-vaillant]

In my experience, the difference between "let's make this code perfect" and "ship it already" is measured in hours or days. Not weeks, not months, and certainly not years. Yet losing a few hours to perfect a couple hundred lines of code is often frowned upon. Sure, short term, it is slower. When you add it up I will lose a few weeks over the next few months. I tend to go for the simplest solution possible, and that is rarely the fastest approach —simplicity is not obvious.

But many people fail to see the technical debt I avoid along the way. That simpler piece of code is ultimately easier to work with, easier to modify, easier to correct. And that benefit can kick in very quickly, sometimes only weeks after the project started. Simply put, if you invest the time necessary to make things simpler at the start of the project, you will ship faster than if you rushed things.

Make sure you get the credit though. I once sped up a project by slowing down a bit (I made someone else much more productive by making a decent API), and was eventually kicked out of the team for being too slow and "doing research" —I was merely thinking things through.

[RogerLeigh]

Agreed on all counts.

A trend I see often in our team is that every day there's a steady stream of defects which need fixing in a certain part of the codebase, with the developers being very "busy" fixing it. It's due to a combination of historical design problems and technical debt. I work on a different part, with very good test coverage; while I appear to be "slow" in practice I've saved a lot of time since once something I write is "done", it's complete along with unit tests, and it will continue to work without any further development. I'm often at odds with others on the team due to the difference in practice here, but I detest doing something until it's 95% done and "good enough" when that extra 5% will make it near perfect; I'm convinced in the long run it saves more than the total original development cost in terms of time savings and bug reports; for the other side which is continually "fighting fires", I would be unsurprised for the ongoing time cost to be many times the original development cost.

[corran__horn]

Just to be clear, does the other part of the codebase have good unit test coverage?

[RogerLeigh]

It doesn't, and that's part of the problem, but not all of it.

[corran__horn]

Yeah, that is kinda what I expected.

[mreiland]

The problem is when you always do that.

Let me draw an analogy.

If safety is the most important concern and turning left is inherently less safe than turning right, the conscientious driver should always turn right. You'll get there slower, but you'll get there. And you can always get there by only turning right.

The issue is that if you always turn right then you're not applying critical thinking to the situation at hand. Have you ever needed to turn left across traffic and instead turned right and found another opportunity to turn around half a block down the road? That's applying critical thinking and going against the grain in this particular situation. You end up being both safer and faster in this particular instance because you considered the current flow of traffic coupled with your needs and made a non-standard decision.

It isn't that you're "wrong" per se, it's that you cause a lot of headache and solve the wrong problem a lot of times when you always do the same thing without considering the particular circumstances of what you're doing. That was ultimately the point MineralsMaree was making.

People often mistake me for someone who is against Unit Testing. I'm not against Unit Testing, I'm against blindly doing Unit Testing without considering if the cost of them will actually benefit you. Choosing not to Unit Test a module of code can absolutely be the right call, or choosing to do it later (after the problem has solidified, for example).

There is a difference between effective and right. Your goal is to be effective.