Excellent rules (57 years). One quibble; I would rate:
Security > Maintainability > (...)
My guiding principles after 20 years of programming (2020)
81–90 of 193 posts
Re: My guiding principles after 20 years of programming (2020)
#82> 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 t…
I would say, that it is not so easy to make this from-small-to-big approach work. It requires planning ahead on another layer. When you develop something small, which is supposed to grow later, you need to make sure to not bake in assumptions, which do not hold for later versions. You need to keep the primitives flexible.
I see this as a basic skill, that we should aim to master at some point, even if we may never truly master this art.
If we do not move carefully around assumptions, we will have to refactor things later, which means more work. Of course moving carefully can also consume time. At some point it may become a tradeoff.
Re: My guiding principles after 20 years of programming (2020)
#83> 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…
> 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.
Me too. Sometimes when I don't feel like I really know how to solve a problem, I'll just write some really hacky code to try to get an answer. Just anything that moves the problem forward.
Then once I understand what I want to do better, I either throw out that code and start clean. Or I just refactor the heck out of it until it is in a good state.
Re: My guiding principles after 20 years of programming (2020)
#84> Never start coding (making a solution) unless you fully understand the problem. It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end. I agree with a lot of the points made by the author (2, 5, 7, and 8 re…
With big projects spanning across years, the "problem" is often a moving target. Adding new features alters the problem space dynamically. The best you can do as a maintainer is to be mindful of the original problem that the solution was architected for, and extend the thing without crossing certain boundaries and assumptions.
> The best you can do as a maintainer is to be mindful of the original problem that the solution was architected for, and extend the thing without crossing certain boundaries and assumptions.
Speaking of boundaries and assumptions, one of the most important realizations I have had about software development is the true meaning of modularity:
Software modules are the things whose boundaries limit the spread of assumptions.
Re: My guiding principles after 20 years of programming (2020)
#85> 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.
I agree.
Re: My guiding principles after 20 years of programming (2020)
#86Few problems with this: > Don’t attach your identity to your code Others in your team will. Example here is a craftsman taking pride in their work. Think about that the next time you are reviewing someone elses work. > Security > Reliability > Usability (Accessibility & UX) > Maintainability > Simplicity (Developer experience/DX) > Brevity (code length) > Finance > Performance Performance is last ? Code length is mor…
I can see where he's coming from. I started around the same time he did and from my point of view from my experience, perhaps I can further explain how I see it.
>Performance is last ? Code length is more important than performance? That's wrong. Also correctness is not mentioned at all surely that has to be in that list.
Depends on the scenario. Early in my career I was maintaining a scheduling DSS. You would enter in some appointments and it would consider a bunch of rules the users would create and find an appointment with matched resources. It was very cool and I really got into it. One of our test cases was scheduling 12 related appointments all at once. After some tuning, our system could do it in about 10 seconds, give or take. I decided to give a prototype a whirl with different ways to store and process everything (in memory) and got it to schedule these 12 related appointments in under a second. I showed my boss and he was impressed, but ultimately said, "the user's don't care about the difference between 10 seconds and 1 second, it's 1000x faster than doing it on paper." When the OP says performance last, I feel this is what he means. Some developers tend to tunnel vision on picking the best set of algorithm and caching mechanisms above all else, allowing the product to face delays when no-one cares about the difference between 10 seconds and 1 second. Of course, this is dependent on the solution. If you are google or Netflix trying to serve millions of users, performance matters. Most of the time, great is the enemy of good in this regard, especially in enterprise apps. Also, you can always tune trouble spots later down the road.
>I bet this person has had a problem with a dep a few years ago that caused a lot of emotional damage and the response is to never use 3rd party deps where possible.
I write stuff in house whenever possible. I've been burned by external libs plenty of times, and there is one I have in my current codebase I wish I didn't. It depends on the quality of your developers, for really good teams, this isn't a big deal at all. I use third party stuff for more specialized libs like image conversion and whatnot. The benefits of in house libs is they only do what you need, so they are tight and when something goes sideways, a smaller codebase trying to satisfy 1 use case is easier to understand than a large lib trying to satisfy 10 difference use cases. Plus, you don't always have access to the source code of third party libs.
>> Good code doesn’t need documentation >This is impractical at the end of the day you'll need to have something for the user to lookup for reference.
Yes, I'm torn on this. I've written plenty of documentation that nobody has ever read but me though. If he means "code with good comments," I'm ok with that. External documentation outside of good tight specs is hit or miss. A lot of it is just check boxing.
>Most devs don't get to decide this they will be told to do X by someone in a large org and given a brief description of why. Refusing to do your work until you fully understand a problem will lead to dismissal.
I don't disagree this happens, but if it does, you're probably in an environment that doesn't respect you, your work or your growth in the company. Get out ASAP. I always explain to my devs why I'm doing something; mainly so they won't write some funky code because they don't understand the problem.
Re: My guiding principles after 20 years of programming (2020)
#87Listing Performance as the lowest value bugs me. I understand that most software isn't performance-critical, you can probably afford to use a garbage collected language for most use-cases. But putting performance last contradicts the high priority of Usability in the list, because Usability strongly depends on performance. Your product might still work if it has a second of lag after every operation, but I won't want…
There are publicly accessible MIT lectures about A&D and computing performance. Part of the taught rationale is that performance behaves like a currency. Some thoughts about this:
The more you have of it, the more you can afford to do. This is interesting to think about. There might be stuff we don't do, that we rule out because we don't even think we can afford doing them. A slightly milder effect here is that we tend to make things more structurally (architecturally) complex and expensive, just because we don't even think of making them fast in the first place. Both of these effects impose real-world limitations and costs.
Secondly, if you don't have enough of it, then you tend to be constantly distracted and limited. Anyone who went through financial hardship for a time knows about the mental, physical and social tax this imposes. I think it is useful to think of performance that way. Or to turn it around: if everything we do and compute was incredibly fast and reliable (also an aspect of performance) then how would that change our behavior, well-being, productivity?
Side note:
Garbage collection is often used as an example in the way I describe above. One can "afford" to use it, or not. But I think this touches on a rather special aspect of performance, which is a broad term to begin with. It affects the overall memory footprint and variance (GC pauses) but doesn't necessarily affect overall latency and throughput, which are more generally applicably aspects.
Re: My guiding principles after 20 years of programming (2020)
#88Earlier quoted context omitted.
To be the devil's advocate, you wouldn't want to pay your plumber for time on his pet project while he's working on your bathroom.
this is such a poor analogy
I give you that, haven't spent much time on coming up with it.
I would like a competent plumber and if he does some fancy work in his spare time and gets even better than great.
But I would raise an eyebrow if beside my work he will also want to be paid for 6 hours he spent in the weekend, experimenting on his bathroom...
Re: My guiding principles after 20 years of programming (2020)
#89Earlier quoted context omitted.
I agree. Coding a solution is my main approach to understanding a problem better. While it is possible to completely understand the problem before writing a solution, it takes much less time to just build a prototype, analyze it to see what mistakes you made, rinse and repeat. Note that the third principle of the "unix philosophy" is[0]: Design and build software, even operating systems, to be tried early, ideally wi…
The key part here is that you shouldn't be afraid of throwing parts (or even throwing wholes) away. Many times we get too attached to solutions to the wrong problem because that's what we built. So in that sense we could rephrase the idea as do not commit to the code you write until you have a good understanding of the problem. Use it as a learning tool.
Yep. It’s fine to explore the problem space by coding. It’s not fine to think you already have the solution and end up coding yourself into a dead end. Ie. solving the wrong problem.
Re: My guiding principles after 20 years of programming (2020)
#90I'll add one:
Code is permanent. Don't rush it. If it takes you 1.5x the time that it should to complete a feature, that is a million times better than rushing something out that is broken. Even if people are waiting desperately and it's a blocking issue. Take your time, get it right once, and move on.