Live data from Hacker News

My guiding principles after 20 years of programming (2020)

alexewerlof.medium.com

61–70 of 193 posts

Re: My guiding principles after 20 years of programming (2020)

#61
post #8

My big tip, always change the problem to fit the resources you have. If the problem is hard, don't solve it, change the problem.

Here’s a fun little story that’s stuck with me for years because it demonstrates this in a very hacker way.

(Forgive the lack of specificities, I tell this as a parable)

A fancy new office tower was opening downtown. Around this time, office space was at a premium so they soon sold out all their floorspace, and the project was considered quite successful except for one small problem; the architect seems to have installed slow elevators.

Tenants began to complain that the ride up to their high, and very expensive, offices was taking too long. These elevators were stupidly slow.

The building management frantically called around the big elevator companies, getting motors upgraded as fast as possible, but the complaints kept coming and in the end no one could quote anything less than $100mil to structurally alter the building to house bigger motors and more shafts.

Then one day an independent construction contractor showed up who offered to do a retrofit to fix the issue for only $10mil. The desperate building management decided to try it.

So the guy took $500k of the money to buy and install a bunch of mirrors in the elevator booths which had been sombre (and expensively) wood-panelled. Sure enough, the complaints stopped coming. (And the contractor got a $9.5mil payday)

The problem wasn’t that the elevators were slow. It’s that people got bored in them (in a world before smartphones). And what do people never get bored of doing? Looking at themselves in the mirror.

Of course, it’s annoying to save the equivalent of 95% of the cost but not see any of that money. You just had to deal with budget cuts that really should have killed any solution. Still a cool party trick I guess.

Re: My guiding principles after 20 years of programming (2020)

#63

> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…

This is why a good IDE is so important. Since I use Jetbrains products (Rider, PhpStorm) I don't worry about refactoring anymore. This results in a very agile way of working.

I believe people underestimate the power of a good IDE.

Re: My guiding principles after 20 years of programming (2020)

#64
The life cycle is related to the solutions quality. Code that is well executed never dies. Specially when hardware has peaked.

I'm biased, but C (client) and Java (server) will never have substitutes.

The reason I can be absolute is that we have run out of energy.

Re: My guiding principles after 20 years of programming (2020)

#65

> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…

Completely agree! This is my number 1 point on my own "I've developed SW for decades, here's what I have learnt"-post:

1. Start small, then extend. Whether creating a new system, or adding a feature to an existing system, I always start by making a very simple version with almost none of the required functionality. Then I extend the solution step by step, until it does what it is supposed to. I have never been able to plan everything out in detail from the beginning. Instead, I learn as I go along, and this newly discovered information gets used in the solution.

I like this quote from John Gall: “A complex system that works is invariably found to have evolved from a simple system that worked.”

From: https://henrikwarne.com/2015/04/16/lessons-learned-in-softwa...

Re: My guiding principles after 20 years of programming (2020)

#66

Show me your flowcharts [code], and conceal your tables [schema], and I shall continue to be mystified; show me your tables [schema] and I won't usually need your flowcharts [code]: they'll be obvious. -- Fred Brooks, "The Mythical Man Month"

I keep telling people this: show me the data structures and I can make a pretty good guess about the algorithms that are used. Show me the code, and I still won't have much of an idea exactly what the data should look like. In modern OOP, with code and data all mixed up and algorithms being injected at runtime with vastly different effects, things can get unreadable very quickly.

What does not separating concerns of data structures have to do with OOP?

Mixing state between a bunch of different backing stores, or not making in memory data structures explicit, makes data structures harder to discover, but what does that have to do with OOP?

Re: My guiding principles after 20 years of programming (2020)

#67

> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…

This is why a good IDE is so important. Since I use Jetbrains products (Rider, PhpStorm) I don't worry about refactoring anymore. This results in a very agile way of working. I believe people underestimate the power of a good IDE.

> I believe people underestimate the power of a good IDE.

Definitely. And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal.

Which, sure, vim is great! And you can get a lot of decent plugins that can make that workable. But gosh IDEs provide so much powerful functionality, why would you make your life harder on purpose by not using them.

That attitude does seem to be fading though, in my more recent experience.

Re: My guiding principles after 20 years of programming (2020)

#68

> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…

I think that line may be more focused on eliminating any known ambiguities in the requirements rather than trying to determine any unknown ambiguities or tackling edge cases and bugs.

Re: My guiding principles after 20 years of programming (2020)

#69
"Realize that every code has a life cycle and will die. Sometimes it dies in its infancy before seeing the light of production. Be OK with letting go."

I cannot disagree more. Code lingers. I work on an 13 years old code base that is considered new by internal standards and it's not uncommon to see lines that haven't been touched for 10+ years.

Re: My guiding principles after 20 years of programming (2020)

#70
post #4

9 times out of 10 somebody else's code points the way. The tenth time, you didn't look hard enough. The exception to this rule lies in a very small % of coders who know who they are. I hasten to add, I am not in that minority!

I realized at about 10 years into my career I would rewrite code as it was easier than learning someone else’s implementation. Now that I’m cognizant of this I first thoroughly review other implementations to try and understand why decisions were made, ultimately saving me from repeating the same mistakes. Inconsistent documentation is also a problem.

My friend at this stage you become a journeyman programmer, if you are able to understand and continue someone else's conception of a reasonably complex domain!
Post reply on HN