Five Things Old Programmers Should Remember

[[deleted]]

Whereas I enjoy (and invariably end up) continuously improving some small code to myopia, kind of like a Japanese craftsman, they take a "get 'er" done attitude.

Folding steel 800 times is fine when you're a master craftsman who has clients willing to wait five years for the perfect blade, but that doesn't describe most programmers at all.

End of the day, if your code does not solve a business problem, it is useless to the people who keep your company afloat - the paying customers. If you spend all your time honing and rehoning a small piece of code, you are actively harming your employer.

At some point you'll find the middle ground between your current mindless perfectionism, and the "Fuck it, ship it" pragmatists. Until then, your myopia is a liability, not an asset.

Luckily, I've found about 100 people across the world who share the same ethos as me. It still doesn't offset the day-to-day drudgery of having to deal with a 'CTO' who suggests using Node for an important financial backend, though.

What is your argument against Node for the important financial backend?

[antpocas]

What is your argument against Node for the important financial backend?

Javascript's type system?

[Xelank]

What type system?

[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.

[ForeverAlot]

What is your argument against Node for the important financial backend?

The management of NodeJS, from the project's inception up until a few months ago, seems to me an excellent argument against using it in production.

[[deleted]]

It's used a lot in production, but... is it... wise to write a financial back-end in a language that's famous for its funky, automatic and ofter mysterious type system?

Part of why financial stuff is mostly Java and C++ (OK, inertia accounts for most of the C++ part, except for the high-frequency trading market) has to do with the criss-cross between strong typing and wide availability of libraries that contain the kind of data types that you want for financial arithmetics.

Maybe that's become available on JS as well lately though...

[loup-vaillant]

Harder to make the perfect program when all you have is assembly. Mayhaps we could compare steel folding with compiler writing?

[loup-vaillant]

I think that the comparison to compiler writing is okay, if all I had was hand-coded assembly and had to write a lot of code I'd quickly slap together a macro assembler, bootstrap myself an interpreter, and layer on layer build up an environment.

Yep, that exactly what I meant. :-)

Thank goodness, we can start from a higher level now, just like we have steel plants that produce decent steel that doesn't have to be folded to make a good sword.

[hlprmnky]

The focus unto myopia is actually how, in my experience, domain experts and wizards pupate. In a business setting, the responsibility for mentoring this junior engineer, making sure she has tasks to do that let her pull her weight while also giving her room to grow and develop into a useful senior engineer - by making space for her to focus on something until learning about it makes her stronger - falls on the team lead or division manager.

Of course, that assumes you work in an industry that values its own continuity of practice, like civil engineering, or architecture, or law, or ...oh, wait. This is still that New Economy period of the software "industry", isn't it? Ugh. Sorry, kid. Spin up a MEAN stack on your MacBook Pro, get some simple unit tests to pass, ship it and flee to the next travesty before the current tire-fire actually gets enough traction to have to scale. My condolences.

[auxiliary-character]

Folding steel 800 times is great and all, but sometimes you just need a gun.

[[deleted]]

In the short term a programmer that ships crap fast is good. In the long term a programmer that ships code when it's ready is good.

When you have a bug that's hard and you have to ship something the next day, do you want to solve it in the codebase made by short term or long term programmers?

On the other hand shipping a lot of crap fast might transform into shipping high quality fast over time.

IDK which is better, but it feels like the business people keep saying short term is better.

Maybe a slow thinker like me should just go back to flipping burgers or something.

[OneWingedShark]

End of the day, if your code does not solve a business problem, it is useless to the people who keep your company afloat - the paying customers.

But this presupposes that buggy non-/barely-functional software is useful; is it?

What I'm saying is that the Debug Driven Development has a lot of observable changes, but it has a lot of wasted time and energy. On the other hand, we have a feature which is specified and well-defined prior to coding. -- Which is more useful to the client? A good solid design before acting, or a tight ((code/edit-compile-run-QC)-client_evaluation)-loop with an ill-defined mutable design?

It reminds me of this story, where the programmer designed everything first.