My guiding principles after 20 years of programming (2020)

https://alexewerlof.medium.com/my-guiding-principles-after-20-years-of-programming-a087dc55596c

by firstSpeaker • 4 years ago

505 189 4 years ago

alexewerlof.medium.com

kqr7• 4 years ago

Amendment to #1: if the right tool for the job doesn't exist, find a cheap way to make the tool. Toolmaking is highly leveraged work.

I like the list! There are some things I would replace with other things (overall, I think I'd emphasise more general business and product development aspects more) but of course, everyone has their own list!

showsover• 4 years ago

I don't know how I feel about the insistence of having pet projects and learning something new every day. It feels like a very work-centered approach to life.

Unless of course the pet projects happen at work during working hours, but finding a place that allows that is probably a whole different kind of beast.

kqr7• 4 years ago

Gather a bunch of co-workers and lobby for 15 % time! You should absolutely have some time for pet projects at work.

andreime• 4 years ago

I think it's amazing if one can claim with a straight face people should `absolutely` be paid for pet projects at work.

codr7• 4 years ago

I don't know about every single day, but I've worked professionally as a software developer since 1998; and I've been writing code for fun outside of work since I got my first computer around 1985.

Work is when someone tells me what to do or where/how to do it, which is why they usually have to pay me obscene amounts to make it happen.

mytailorisrich• 4 years ago

Once you've settled into a programming job there is actually very little that is new and intellectually challenging. If you don't do anything else you'll become obsolete and atrophied.

To have pet projects is to break out of this daily slow death and to keep learning and being intellectually challenged while keeping up with the industry.

tluyben2• 4 years ago

I still (after over 30 years as pro) develop stuff for fun on the site. I don't see that as work (and I don't see my work as work either these days either).

oohaargh• 4 years ago

This one's very personal, it's only a good thing to do if you genuinely really enjoy it.

I used to be a maths teacher and I love maths, and would do it for fun outside of my job. That in turn often helped with the job itself, and certainly helped to keep my interest in the subject alive even when 90% of the job was teaching fairly basic stuff that wasn't particularly exciting.

I'm now a software engineer - I'm much happier in my job, but I don't love writing code enough to ever want to be doing it outside the 40 hours a week I'm paid for. I'm slightly jealous of the people who do, because I know first-hand that it's a great way to do better at work and keep feeling fresh and interested in what you do, but forcing yourself to do it doesn't bring any of the same benefits.

ggm• 4 years ago

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!

dijonman2• 4 years ago

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.

hackerfromthefu3• 4 years ago

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!

gonzo41• 4 years ago

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.

rablackburn3• 4 years ago

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.

alanbernstein• 4 years ago

Fake progress bar?

orlp• 4 years ago

Here's one more from me: count your liabilities.

1. Code is a liability. No code? No bugs. The best commit is one that removes unnecessary code. This includes dependencies.

2. State is a liability. Multipliers for: hidden or non-obvious state, shared state, externally (by actors you don't control) accessible state, concurrently accessed/mutated state. Often the worst offenders are environment settings/configuration, such as Windows Registry, environment variables, installed dependencies, daemon services, etc, scoring full points.

3. All publicly observable behavior is a liability. Also known as Hyrum's Law: "all observable behaviors of your system will be depended on by somebody", or https://xkcd.com/1172/. Huge multiplier for systems with a long expected lifespan, and another huge one if you guarantee backwards compatibility to paying customers. Program under this assumption, and if you can hide or control your internal behavior, do it. E.g.: maybe don't output results reliant on a HashSet order - sort them.

None of these are hard 'rules'. Often the liability is necessary, or worth the saved effort or gained feature. But be aware of them, and minimize them where possible.

Cthulhu_• 4 years ago

I'd add developers as a liability, notably bus factor; if you have only one dev that knows tech X or product Y, you need to get rid of tech X / product Y, or hire and train more people that know tech X / product Y.

Don't keep adding new technologies to your tech stack, it increases complexity and bus factor. I'm saying this as a warning as well because I've witnessed numerous projects where they switched to a new technology or tried to rebuild their tech stack, only to go back once the consultants and self-employed folk got bored. They hired external people to accelerate without having them focus on handover and building up their own IT department.

kqr7• 4 years ago

E.g.: maybe don't output results reliant on a HashSet order - sort them.

I would much prefer shuffling them in that case. Less expensive and reduces the size of the public API. (Returning items in a specific order, whichever it is, still is a sort of promise.)

silvestrov• 4 years ago

One gotcha is that some SQL databases automatically sort items when you do a GROUP BY.

Then a few releases later the database switches from a B-tree to a hashmap for the GROUP BY internals and now your output is no longer sorted.

mitchs• 4 years ago

"all observable behaviors of your system will be depended on by somebody"

Ugh, a former team I was on had that to the extreme. We were customizing open source software for internal use. A lot of operators had (over years) developed scripts that would just SSH in and use a CLI to interact with the software, using regex to parse output. We once thought we were safe adding a new line to the output rather than modifying an existing output line. Nope, someone somewhere used a multi-line regex.

Kicking everyone's automation out of the shells of those boxes was a multi-year project that is, as far as I know, still ongoing.

i_like_robots3• 4 years ago

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 really resonate with me too) but I think this one is my favourite. One strategy I've used which is successful - but not very popular - is "readme based development". The concept is simple, if we're building something new then the first thing we should do is summarise the project in the readme. If we spend time describing the problem and scope of the project and finessing it down to a few sentences before we start coding then we should have a better chance of staying on track and have an easier time communicating with others. The bigger the project the more useful this can be but unfortunately the majority of folks I've worked with do not like writing.

bennysomething• 4 years ago

Readme based development sounds like a great idea!! Thanks.

aloisdg• 4 years ago

"Doc > Test > Code" is something I can get behind :)

thejosh• 4 years ago

Internally where I work we use RFCs if we want to propose a new feature/addition, it helps bring others in to skim the doc to find out if there is anything they need to add. It's not too bad, I quite like this

bluetomcat• 4 years ago

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.

i_like_robots3• 4 years ago

Absolutely, we can always try to assume that our predeccesors or past selves had the best of intentions but nothing beats writing down the context and problems at that moment in time for future reference.

xnormal• 4 years ago

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.

catwell• 4 years ago

This point makes literally no sense to me. He says don't start coding before you fully understand the problem, and then he says the way to explore the problem space is coding (the code-test-improve cycle).

By the way I agree with the last part. Sometimes the best way to understand the problem is writing a half-broken solution for it. You just have to be aware that what you're writing probably won't solve the problem, and make sure all the other stakeholders are aware too (that's usually the hardest part).

dgb232• 4 years ago

I agree. There is exploratory coding. It’s a bit like talking to yourself (or your rubber duck) or writing things down, or drawing. It’s the kind of thing you do to load up your head with inputs to just play and it’s incredibly powerful.

hvidgaard• 4 years ago

I usually go about it differently than hold off coding. I do try to understand the problem fully before I implement anything. I try to figure out what abstractions make the most sense and what to optimize for. Then I write a preliminary implementation and almost without fail I learn something new that changes the parameters of the "problem". Scrap it and do it again just with more knowledge. No amount of analysing and understanding up front have produced a better or faster result for me.

willcipriano• 4 years ago

I've found this sentiment is common among people who dislike coding. They feel code is a burden and do whatever they can to minimize the amount of it that they do.

I've consistently outproduced peers by picking up the compiler early in the cycle and throwing away what I've done if it isn't working out. It requires a bit of self awareness, judgement and taste to know if something isn't going to work but I think the people who hate coding also can't stand throwing effort away like that.

neogodless• 4 years ago

I think it's key to think about the wording here

understand the problem
code-test-improve cycle

I think you're first trying to understand a non-programmatic problem, a business problem, a user problem. Then you start to explore the solution to that problem. Yes, you'll learn more about the "problem" as you solve it, but the cycle explores how you're solving the problem.

anamax• 4 years ago

It should be easy to talk a pointy-haired boss (PHB, see Dilbert) into "readme-based development" (RBD). In fact, you can probably get funding for training, aka pizzas.

That's because RBD is basically Amazon's "write the press-release first" methodology and no PHB will say "we won't use something that Amazon says makes them successful."

The pizzas come from another Amazon saying.

beardyw• 4 years ago

Taken individually these items are valuable, but I am not sure about these kinds of lists. My own list would have changed each decade of my career. 10 years - idealism, 20 years - compromise, 30 years - realism, etc. It would be good to see a review by the author in 10 years.

booleangate• 4 years ago

It takes 20 years to learn to compromise? I would expect these kinds of lists to change very little after the first 10-15 years.

pixel_tracing• 4 years ago

Does FAANG still ask you to Leetcode after 20+ years of experience?

yodsanklai• 4 years ago

Yes, if you apply for a SWE position.

Mawr• 4 years ago

experience != skill

Experience is merely the prerequisite for skill, it doesn't cause it.

weatherlite• 4 years ago

If course, and algo whiteboard sessions. It's even harder for seasoned devs since they graduated ages ago.

Yuioup• 4 years ago

A great list!

usrbinbash4• 4 years ago

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 edge cases or undefined cases (especially in naturally grown business-logic)

c) because what the problem actually IS, is often not that clear at the start of the problem. Yes, in an ideal world, changing requirements would wait until the next version, however, sadly that's not what happens in the wild.

pan69• 4 years ago

I call this, Insight by Progress. I.e. the further you progress into a problem the more insight you gain.

Personally I have never 100% solved a problem before writing any code. For me it really the other way around. By writing the code I better understand the problem.

I guess what we're dealing with here is that different brains solve similar/same problems in different ways. I guess its also the reason that advice such as "Never start coding ... unless ..." doesn't work for everyone.

usrbinbash4• 4 years ago

I guess what we're dealing with here is that different brains solve similar/same problems in different ways.

I think the main difference is between human brains and machines. Biological systems operate with a kind of "fuzzy logic" by default...glancing over edge cases, smoothen out discrepancies on the fly, filling in missing information with context knowledge or assumptions, etc. Being imprecise is not a problem, in fact being able to handle the imprecise, is what keeps living things going.

When we describe a problem to a human like "take that crate and put it in the next room", we know that he will fill in the gaps (hopefully) like not assuming that the cleaning closet is the "room" we meant, even tho its right next to the starting room, and its technically a room.

Describing this to a computer is different. Edge cases need to be considered. What if there is no crate? What if there are many, which one does he need to get? What does "in the room" mean? Does the orientation of the crate matter? What do I do when the room is full? "Next" on which side of the corridor? And so on, and so on.

Only in having to describe a problem in an algorithmic way, can we fully appreciate all of its parts, and the information flowing through the process.

paskozdilar3• 4 years ago

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 within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

[0] https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s...

koide• 4 years ago

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.

Hendrikto• 4 years ago

If you read ahead two sentences:

You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end.

So the author seems to agree, somewhat contradicting his own point.

quickthrower2• 4 years ago

If like most of us you are working on legacy (as opposed to greenfield) then the existing code is a part of the problem space. Coding (and debugging) is a good way to understand that problem!

2OEH8eoCRo0• 4 years ago

This one is weird but I agree with the gist of it. You shouldn't be coding until you understand the problem and have a high level design planned out in one form or another.

is0tope2• 4 years ago

Definitely agree. I think some people find it controversial these days with agile etc but i think making prototypes is a severely underrated skill and practice. Not all problems are obviously tractable from the outset by pure analysis. Sometimes you need to build something out of cardboard and rubber bands (figuratively) to see if it will work. Was a topic I wrote an essay about some time back (https://www.machow.ski/posts/galls-law-and-prototype-driven-...).

renewedrebecca• 4 years ago

The weird danger of making prototypes are managers who think having a prototype means you're almost done with the whole task.

This is especially bad when the prototype works, but doesn't work well. They think you just need to polish things up a bit when really, you need to take what you've learned and build the real deliverable.

blenderdt• 4 years ago

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.

whynotminot• 4 years ago

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.

henrik_w• 4 years ago

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

_hcuq• 4 years ago

Your principles are better than the OP’s.

zelphirkalt• 4 years ago

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.

derangedHorse• 4 years ago

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.

dhimes• 4 years ago

I agree.

timmg• 4 years ago

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.

JKCalhoun• 4 years ago

Yeah, it could just be me, but I prefer to make two false starts, toss them, and then get it right on the third attempt rather than attempting to whiteboard the problem for two weeks.

Not only is it more interesting to me to try three different ways to tackle a problem, but I have been burned when the two weeks of whiteboarding missed something and I'm back to having to iterate anyway.

To be sure, I do a little whiteboarding, but generally it might be about 2 hours or so of sketching out ideas, major structures, code flow ideas.

I generally was nodding along to most of the author's points though.

I definitely have grown to divorce myself from my ego and always try to not only try to shine the spotlight on my younger coworkers (new engineers) but try to give them "ownership" of key pieces to allow them not only some sense of autonomy/ownership but a sense of pride as well.

That does go slightly against some of the author's points about collaboratively working on a project. Engineers need a part of the code (let's say an image cache manager, as an example) that they can "own" though in order to grow. You don't want an engineer to always have "training wheels" on. (And frankly, I think this is one of the things I dislike about code reviews, I think it dis-incentivises autonomy.)

The team though, let me be clear, is the most important part of any project, not the individual luminaries. The "team" though, to a degree, needs to have engineers who feel an ownership stake in pieces of the product.

(FWIW, I have probably 35 years of programming experience, ha ha.)

Palomides• 4 years ago

I forget where I read this, but something like:

first time to understand the problem

second time to understand the solution

third time to do it right

spikej2• 4 years ago

I take the original text as "don't just jump into coding right away" which I've seen so many people do. As you said, take a little bit to process and think through it, then start out your pseudocode, etc.

mandevil• 4 years ago

Fred Brooks' other famous bit (besides the "mythical man month"): "You should plan to throw one away. You will anyway."

verinus2• 4 years ago

me too...

I usually so a vertical proof of concept where I tackle each step I understand in a unit-test. ofc it's no unit test- the test framework just serves as an quick entry point where I can test different approaches next to each other or different versions/variants of each approach.

like a repl with the benefit of an easy view of my "history" with the ability to step back in time.

omginternets4• 4 years ago

That's not coding the solution though, that's exploring the problem.

Obviously it's helpful to formalize the problem! This is no different from manipulating mathematical equations on a piece of paper. =)

fizx• 4 years ago

This is pretty similar to the "pantsers vs plotters" debate in creative writing. Do you need an outline before writing a novel? How much of one?

syngrog662• 4 years ago

both. you absolutely benefit from being free to improvise and follow the creative muse when pen on paper

you also need a well-thought out outline for any larger work like a novel, or, it will be a disaster, or at least not be anywhere as good as it could have been

credentials: creative writing for decades and experienced 1sthand tradeoffs of each. my verdict? seek the Hegelian dialectic. ;-)

seanmcdirmid• 4 years ago

I think this is common for many programmers. Programming isn't just a way to implement the solution to a problem, it is also a way to find solutions to problems (by working them out in code). Often times, programming can also help you figure out what the problem is. Programming isn't just about implementing things, it can also help with thinking.

bsedlm• 4 years ago

the 'beautiful' thing about this, is that it's then impossible to convince product people and "stake holders" to authorize enough time and resources to improve the solution afterwards.

In my experience they'd only relucantly agree if and only if it's "do this or die". Which then happens under time-pressure or under stress factors of other kinds.

"if it already works, why fix it?" (because it's making developer's lives much more difficult than they could be? --"but how does this increase revenue?" --errhmm... because incresaingly difficult to maintain? but they don't care about this "that's your job")

CRConrad• 4 years ago

it's then impossible to convince product people and "stake holders" to authorize enough time and resources to improve the solution afterwards.
"if it already works, why fix it?"

I suppose one attempt at a fix for this would be to make the user interface of your prototype the least prioritised part; maybe even go out of your way to make it ugly and clumsy, so the thing as a whole looks more like a prototype and less like a "solution".

munificent• 4 years ago

This idea is the source of Fred Brooks' observation: "Plan to throw one away. You will anyway."

In order to implement a good solution you need to understand the problem well. Often, the only way to reach that level of understanding is by trying and failing to implement it.

These days, with modern refactoring and incremental development, it's less throwing away a whole program and more gradually refactoring it until little of the first code remains but I think the observation still holds in many cases.

zarkov99• 4 years ago

I think this depends on the scale of the problem. For small, algorithmic, problems, the kind you would see in a coding interview I find it far more efficient to solve on paper, or on your head, before getting bogged down in code. The difficulty in these types of problems is not understanding the issue but coming up with a solution. For much larger problems, just getting you head around the problem is very challenging and you need some scaffolding, in the form of half-backed, but still precisely described solutions, simply to provide ballast to your thought process.

MrPatan• 4 years ago

Analysis through synthesis

polishdude202• 4 years ago

In a way, coding can be thought of as two distinct things.

One: coding is a way to play around with ideas, equivalent to a back of the napkin calculation, a diagram in the sand or a pencil sketch of a part. We use code in this scenario more as a way to write down our thoughts and process. But rather than writing in just pure English and writing an essay or a set of Todos, we write more detailed "specs". "Do this three times or until this value is zero" is also written in code and perfectly understandable in code too.

Two: code is used to run by a computer to produce an outcome. In this case, the back of the napkin sketch IS the part but more thought out.

Society is so used to there being two material objects between the "plan" and the"final product" that we forget that code is different. With code, the plan and the final product are of the same form. Of the same physical space.

marssaxman• 4 years ago

The same distinction still holds in programming - it's just that the process of using the plan to generate the final product has been automated, by that handy class of tools we call "compilers".

jhgb• 4 years ago

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

I'd go as far as to say that programming is a good medium for expressing poorly understood and sloppily formulated ideas. Oh, wait, someone else already said that...

keithalewis• 4 years ago

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"

lelanthran• 4 years ago

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.

hackerfromthefu3• 4 years ago

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?

ohhnoodont• 4 years ago

10. When making decisions about the solution all things equal, go for this priority: Security > Reliability > Usability (Accessibility & UX) > Maintainability > Simplicity (Developer experience/DX) > Brevity (code length) > Finance > Performance

In my experience simplicity is the cornerstone priority that nearly all other attributes stem from. Simpler solutions tend to be easier to rationalize/debug, leading to systems that are more maintainable, more reliable, and generally more secure (see OpenBSD). This is of course not an absolute rule but I've found success by always being cautious when introducing complexity and investing extra time to explore/discover simpler approaches.

The author shows they have this insight in points 2, 11, 13, 17, and especially 19, but didn't really represent this in their list of priorities. Simplicity is more than DX.

yetihehe• 4 years ago

That ordering just states that you should not sacrifice security for simplicity. As long as two solutions are equally secure, the simpler one is better, but not when simpler one is less secure.

Simpler solutions tend to be easier to rationalize/debug, leading to systems that are more maintainable, more reliable, and generally more secure (see OpenBSD).

Yeah, IF they are more secure, THEN use simpler solutions.

adverbly• 4 years ago

Totally! Simplicity is core to the rest of the others in the list.

The other weird one is finance near the bottom. Typical engineering bubble style thinking... make sure your solution actually provides value and that people will pay for it! Otherwise you're wasting your time solving the wrong problem! The importance of that cant be understated!(unless your goal isn't to provide value of course)

stonemetal12• 4 years ago

I guess it depends on what "decisions" we are talking about. I took it to mean design decisions, in which case Security and Simplicity are generally orthogonal.

Plain text passwords are a lot simpler and less secure than salted, hashed passwords. Using bcrypt to hash your passwords is a lot simpler and more secure than some home-grown, self-implemented hashing algorithm.

Also as it says he is talking about priorities, if something is simpler and less secure then choose security. If something is simpler and more secure then hey double win.

dustinmoris2• 4 years ago

Bugs take shelter in complexity. “Magic” is fine in my dependency but not in my code.

I disagree with this. Dependencies become your code and any magic will always come and bite you, no matter if it's written by you or a downstream dependency.

The guiding principle should be: Reject magic at all cost

fullstackchris3• 4 years ago

I disagree. For a huge majority of projects and teams, it is infeasible to build everything in-house. The way I see it, you can either

1. take an extremely impractical amount of time reinventing the wheel in house, or

2. take a (IMO a relatively much smaller) hit when you fail to take the 10 minutes to read the breaking changes on the dependency. Read this, make fixes, and everything is working again. If you hit a major issue like this with your own tooling, you're at the mercy of your team's ability to quickly build a fix.

A refined version of this point may be something like "only use dependencies which are very well tested, documented, list known issues, and have an active community of development and releases" - don't just install any package or library because "it appears to solve my problem"

dustinmoris2• 4 years ago

My point is take dependencies, just skip the magic ones because they are vile

fullstackchris3• 4 years ago

Any function that’s not pure should be a class. Any code construct that has a different function, should have a different name.

I definitely haven't been following this... anybody else using nearly 99% of functions in their frontend work? (Typically I'm in the React TypeScript world)

rablackburn3• 4 years ago

I’m from the same world as you and here’s how I understood this:

Any function that’s not pure should be a ~class~ component.

ie, when you have a bunch of functions that operate on the same kind of struct/set of state, and in fact you want to prevent other functions from messing with it (you want to make it internal), you group them in some way. The OO word for that is a class. React is a component; which are much more composable because we ditched the stricter concept of inheritance of OO classes.

Hell, the es6 class system is really just syntactic sugar around Brendan Eich’s nifty prototypal system. If it weren’t for the weak typing and lack of std.lib, JavaScript would be an amazing language.

…which is to say it would probably be Go haha

fullstackchris3• 4 years ago

But what about hooks? These essentially break this point completely. Functions that literally have (side) 'effect' in the name! (useEffect)

Over the past few years, at least on the frontend, I've found in every case what is a class could be expressed in a function or variety of functions. So yeah, still unsure about this point, maybe it was more for other software domains (backend, embedded, etc)

Funny too about what you say about 'grouping functions in some way'... I just made a post about how it makes a lot of sense to put a single function per file... with my organizing, a named folder is the only thing that 'groups' my functions together... so far this style of organization is working well for us.

https://chrisfrewin.medium.com/advanced-code-organization-pa...

ur-whale• 4 years ago

I see much in there that aren't general principles at all but rather a reflection of the author's personality and preferences.

In other words: I'd be wary of sticking to these unless they fit who you are and the conditions in which you operate at your best.

einpoklum• 4 years ago

Don't fight the tools: libraries, language, platform, etc.

That means you'll always be stuck doing things using existing paradigms. Which is fine if you're only developing an application, but not fine if you want to effect more fundamental change.

Never start coding (making a solution) unless you fully understand the problem

Sometimes, I cannot understand the problem until I've started coding.

Tech debt is like fast food.

Yes, in the sense that where I work, many people have it every day :-(

go for this priority: Security > Reliability > Usability etc.

I don't buy that gradation.

Don’t use dependencies

Contradicts a bunch of other points IMHO.

Any function that’s not pure should be a class.

No. Verbs are not nouns. But - if he means functions with static variables, then maybe.

Software is more fun when it’s made together. Build a sustainable community.

Very difficult in my experience. In a commercial setting, the company controls your software, and it's a totalitarian 'community', if at all. With your pet projects, it's often difficult to attract users to participate more actively.

hackerfromthefu3• 4 years ago

Well you can extend the tooling to suit your needs. As Steven Covey says, sharpen the saw.

aa-jv2• 4 years ago

I think #1 is:

Rule #1: Software is a social service. If you're not writing for the user, but rather for the sake of writing code, you're not a good programmer. Write for the user, whether that user is Joe Sixpack or Jane Hotdev, or even if you are the user - assume the role of servicing the end user. Software is a social service.

criddell• 4 years ago

Is every job a social service?

aa-jv2• 4 years ago

Pretty much. The money to pay for the work, has to come from somewhere. Usually that is a person/organization/society.

But software specifically is social, because software is useless without a user.

barberpole• 4 years ago

"Pick the right tool for the job" --- exit

andrewmcwatters• 4 years ago

It’s my litmus test for idiots who think they have something useful to say.

janandonly• 4 years ago

I love this one:

Bugs’ genitals are called copy & paste. That’s how they reproduce. Always read what you copy, always audit what you import. Bugs take shelter in complexity. “Magic” is fine in my dependency but not in my code.

bullen• 4 years ago

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.

rvr_• 4 years ago

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

TameAntelope• 4 years ago

I dunno, trying to independently rediscover what’s in The Pragmatic Programmer doesn’t seem like the best way to learn. At least not the fastest.

Every one of these is covered by lessons that OP didn’t have to learn themselves if they had just paid attention to the guidance available from luminaries in the field.

This leads me to the one lesson I’d give instead; let other people do your work for you, whenever you can. #13 on this list is far too strict, you’ll spend your days maintaining commodity code and discovering for yourself all the pitfalls someone else could have just solved for you.

If you’re looking for the definitive version of this, definitely check out The Pragmatic Programmer.

andai2• 4 years ago

Listing 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 to use it. And if there aren't any decent alternatives, I am going to experience irritation and sadness on a continuous basis.

Jonathan Blow said[0] (5 minute interview) that software authors have an ethical responsibility towards their users. How many people use YouTube, or Windows? The time wasted might be small on an individual scale, say a minute a day, but multiply it by a billion people (eg. YouTube or Windows) and that's 16 million man-hours per year.

I'd argue the same responsibility exists just as strongly even if you have one user! Do you want to frustrate her, constantly waste her time? Of course not! She is not going to be very happy with you if you do that :)

[0] Jonathan Blow on Success and Ethics in Software Development https://youtube.com/watch?v=k8gIJOy0c2g

dgb232• 4 years ago

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.

a9h74j2• 4 years ago

"Performance serves usability" is, to me, another very strong reason to do at least some prototyping very early.

andai2• 4 years ago

I don't understand the connection, could you please elaborate?

spikej2• 4 years ago

Valuing performance has indirect effects on other things: you're forced towards better models, better SQL queries and better validation/verification of data.

cosmotic• 4 years ago

All those things also come from valuing things earlier in the list: Reliability, Usability, Maintainability, and Simplicity

juangacovas• 4 years ago

My opinion is that too often we say "good enough" performance, let's optimize later if this degrades overtime... And there we are, sometimes creating time-bombs of performance degradation just for the sake of delivering features the faster the better... When you have to clean up and refactor other people mess because it's a clusterf*ck of "just works", you begin to appreciate some basics rules and "dont's" about doing things in software

ravi-delia2• 4 years ago

But putting performance last contradicts the high priority of Usability in the list, because Usability strongly depends on performance.

Well that's why usability is its own item. Whatever is needed for usability is ranked as important by the list. If indeed your users find that their button clicks are just so very fast you need handrolled assembly to keep up, then writing that assembly is vitally important. Otherwise? Probably not so much. Performance for its own sake is last priority.

Now obviously there's a coherent argument that in general performance isn't considered enough when evaluating usability. That's totally fair, and probably true.

oswamano• 4 years ago

Stay clear from hype-driven development.

Man i still remember when it felt like a new js framework was coming out every day

Dave3of52• 4 years ago

Few 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 more important than performance? That's wrong. Also correctness is not mentioned at all surely that has to be in that list.

Don’t use dependencies unless the cost of importing, maintaining, dealing with their edge cases/bugs and refactoring when they don’t satisfy the needs is significantly less than the code that you own.

https://en.wikipedia.org/wiki/Not_invented_here

It's impossible to determine the cost of using a lib using these metrics. 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. That's not a professional response to what happened it that's the case I'd hope most Staff Engineers don't have this attitude.

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.

Never start coding (making a solution) unless you fully understand the problem

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.

Some good stuff in there but also some problems.

Clubber2• 4 years ago

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.

Dave3of52• 4 years ago

Eeek

our system could do it in about 10 seconds, give or take
user's don't care about the difference between 10 seconds and 1 second

They d,o but your boss doesn't. That is until they complain. Happened to me multiple times over the past 16 years. No one cares about Performance until it's too bad then suddenly it a huge problem. I've been in several projects where fixing performance was a rewrite due to this attitude. Performance should be much higher on the list period. Also not having correctness is insane.

I've been burned by external libs plenty of times

Yes and you're not the only one but the "I've been burned therefore noone can use 3rd party libs" is childish.

A lot of it is just check boxing.

That's presumably coming from someone who has a lot of experience and is very familiar with the domain. For those who are new to the company and new to working in tech in general good documentation is a godsend.

Get out ASAP

Ah yes, heard this many times. It's completely impractical and often comes from people in an privileged position. Not all devs are paid high amounts and can quit their job on a whim.

yoyohello13• 4 years ago

Good code doesn't need documentation.

Here's the full quote from the article: "Good code doesn’t need documentation, great code is well documented so that anyone who hasn’t been part of the evolution, trial & error process and requirements that led to the current status can be productive with it. An undocumented feature is a non-existing feature. A non-existing feature shouldn’t have code." Maybe you're just objecting to the first part, but he isn't saying "don't document".

GnarfGnarf• 4 years ago

Excellent rules (57 years). One quibble; I would rate:

Security > Maintainability > (...)

ramesh31• 4 years ago

I'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.

hiepph• 4 years ago

While living in Italy i learned this idiom "Chi va piano va sano e va lontano". It means "who goes slow and steady wins". It has fundamental impact on my work career. Now I don't rush to learn new tech stack but take things more slowly and immerse myself in it.

"The only way to go far is to go right".

btbuildem• 4 years ago

#18 will take most people that long (a couple of decades) to actually follow. And it's the most important one. Even on OP's list is near the end, IMO it should be the first point.

shireboy• 4 years ago

All good guidelines. A corollary to 1) don’t fight the tools, use the right tool is that you have to know lots of tools. Or at least, enough of several tools to know when to pull out which tool. Otherwise, “if all you have is a hammer, all problems look like a nail”.

I implement this by reading industry news, “spiking” projects for interesting frameworks, ides, etc. I find it helps to go broad in learning- learn a little about lots of things, but then deep dive when interest or need arises.

ChrisMarshallNY• 4 years ago

That's a great list!

I feel like he "gets it."

#10 is my fave:

When making decisions about the solution all things equal, go for this priority: Security > Reliability > Usability (Accessibility & UX) > Maintainability > Simplicity (Developer experience/DX) > Brevity (code length) > Finance > Performance But don’t follow that blindly because it is dependent on the nature of the product. Like any career, the more experience you earn, the more you can find the right balance for each given situation. For example, when designing a game engine, performance has the highest priority, but when creating a banking app, security is the most important factor.

I would add "Localizability," just before "Usability."

In my experience, security and localizability need to be integrated from the very first line of code. They can't be added after the fact.

omginternets4• 4 years ago

I like the tech debt quote:

Tech debt is like fast food. Occasionally it’s acceptable but if you get used to it, it’ll kill the product faster than you think (and in a painful way).

However, I would have worded it more strongly:

Tech debt is like cocaine. It will make you unnaturally productive, until one day it doesn't.

My point here is twofold:

1. The speed with which which the worm turns is underestimated by Silicon Valley "move fast" culture.

2. The obsession with go-to-market speed in SV and SV-adjacent companies is extreme. In some sense, it's as extreme as the lets-take-blow-and-get-rich finance circles.

There is certainly something to be said for iterating quickly, and it is likewise true that engineers have perfectionist tendencies, but I think our industry has taken a good thing much too far. Going to market has more to do with being focused than with doing sloppy work. Slow is smooth, and smooth is fast.

taeric2• 4 years ago

I think you both oversell it. Debt, as the metaphor, implies borrowed something. You could be borrowing effort from pulled in libraries. You could be borrowing future maintenance time. Both can be valid choices. Both can be success or failure.

So, if you have the time now to not borrow, don't. But if you can leverage growth to have more future resources to pay back on debt, you should probably do so.

omginternets4• 4 years ago

That's fair. My post is mostly a reaction to the fact that tech debt is rarely (read: never) handled correctly, i.e. as debt to be paid back with interest. It's instead an excuse to burn the candle at both ends.

zild3d2• 4 years ago

How much cocaine is reasonable to do then? And how frequently?

omginternets4• 4 years ago

That's exactly my point. If you find yourself in a situation where cocaine is necessary to achieve success, you're not in a healthy situation.

From there, I have no good answer. Some people will take it once or twice, succeed, and be fine. Others won't.

giantg2• 4 years ago

My 10 years have given me one principle - make money. I don't want to work like this forever.

conjectures• 4 years ago

Avoid overriding, inheritance and implicit smartness as much as possible. Write pure functions.

Amen, preach it from the mountain.

Can't say I agree performance is bottom of the priority pile. As someone who does numerical work semi regularly, performance can radically change the usefulness of software (interactive versus batch for example).

tapatio• 4 years ago

I have more experience than you and agree with what you say. Your guiding principles coupled with 12 Factor are a solid foundation for software development.

wly_cdgr• 4 years ago

Lost me at #3

unixhero• 4 years ago

Inventing on principle: https://www.youtube.com/watch?v=PUv66718DII Thank you Bret Victor

billti• 4 years ago

great code is well documented so that anyone who hasn’t been part of the evolution, trial & error process and requirements that led to the current status can be productive with it.

Just the other day I was doing a code review where the code itself didn't have a single comment in it, yet the PR had several notes for the reviewer around why something was done a certain way, the failed approaches, unexpected behavior they had to workaround, etc.

My response, "Please put all this information into comments in the code so the next person to work on it doesn't have to figure all this out again".

If code was tricky enough that it took you down several unexpected paths to get a few lines right, take the time to note that in the code for the next poor soul to work on it. (Which may well be yourself in a few months when all those lessons are forgotten).

Tarucho• 4 years ago

After 20+ years as a dev I´ll say that the first item in the list should be: understand your organization, boss and coworkers first.

What you do should be based on that analysis. If not, frustration, dissapointment and conflict (internal, external) will follow.

worik• 4 years ago

The thing I learnt at about year three was "if there is a solution that does not require new software, use that"

At the time it was early days for personal computers (1991) and the doctors in our organisation were very resistant so the clinical booking system became a board with cards in it.

These days people are much more used to computers, and have their own, but there is an underlying principal, closely related to KISS.

Software will not eat the world. If it can be achieved without software it will likely (not certainly) cheaper and more reliable.

An example? Controlling a machine. Hydraulic systems are well understood, very effective. Putting a computer into the system generally decreases reliability for very little benefit.

And has crashed quite a few aeroplanes.

irrational• 4 years ago

Always have pet projects.

I strongly don’t agree with this one. In my opinion, a well rounded individual will have hobbies and a life outside of programming that won’t leave time for pet projects.

Having said that, I do have a pet project that I’ve been “working on” for about 15 years. Maybe I’ll find some time to make some progress on it after I retire.

barrucadu• 4 years ago

Why can't someone be a well-rounded individual with hobbies and a life outside of programming, and also have time for pet projects?

WalterBright• 4 years ago

Never start coding (making a solution) unless you fully understand the problem.

If that were only possible.

For example, say you want to write a C compiler. You have a C Standard as a guide. Nobody fully understands it. And implementing the Standard is only a small part of implementing a C compiler.

Your implementation isn't going to survive first contact with a user, either.

P.S. Paul Mensonidas is the world's leading expert on the C preprocessor. That's a good indication that nobody else understands it :-)

Don't worry about it. Just start implementing the parts you do sort of understand, and keep iterating.

gorgoiler• 4 years ago

If something feels wrong to you that means it is almost certainly wrong. There are so many things I’ve seen that made me go “hmmm, that’s odd”, which I ignored to my peril.

An assert that doesn’t quite make sense. An argument type that feels too specific. A hang in ssh once in a while.

7 times out of 11 they’ll turn out later to be the first sign of an error you wish you’d looked into sooner. I guarantee it, 82%.

nhoughto• 4 years ago

yep agreed.

I've often thought about what interesting findings you would get back if time and people were infinite and all those little things you thought, 'huh? thats weird' and put it in a queue somewhere and a few days later it had been thoroughly investigated and findings documented by some smart person. I'd expect you'd find some weird networking problems for why ssh hangs sometimes, misconfigurations, waste, security vulns etc. So many things we skip over day to day bc it would be a distraction.

ternaryoperator• 4 years ago

Good code doesn’t need documentation

It's amazing how this POV lives on, even in an essay which decries technical debt. Documentation and well-written code fill different roles with only some overlap. Your code can be beautifully written, but if I need to read the whole 500+ lines to figure out what you're doing, rather than read a single paragraph at the top of the file, you've burned through a lot of my time. Good documentation explains the why, code explains the how.

mbrodersen• 4 years ago

I have been programming professionally for 25+ years and I pretty much agree with the author. One thing I want to add is: “95% of tech problems are recreated by the developers themselves” :)

tau5210• 4 years ago

In general, I'm pretty skeptical of imperative guides like this. Such statements only focus on one side of the coin. So while it may have an element of truth as long as you are absorbed only on that one side, you risk completely missing the other side.

For example: > Deprecate yourself. ... Don't own the code.

On one hand, this is true: ultimately, you want the code to be independent of you. But on the other hand, I've witnessed bad code quality proliferate in a repo many times because no one is taking ownership of the code they write: they just write enough to finish the task and move on. And it rarely gets caught in code reviews either because all the other members are operating in the same mindset too. His principle misses this side of the coin.

Over the years, I came to realize that at least for me, there is one root force behind almost everything for me, including how I code, how I interact with members, etc. It is: responsibility. I am simply trying my best to write responsible code, create a responsible product, be responsible to my team members and colleagues, etc. The rest of the stuff (like what you might call 'principles') are just specific manifestations of this feeling. e.g. code ownership: I need to own my code to the extent that I need to be responsible for my work, but on the other hand, it is also my responsibility to ensure the code does not depend on me forever. Albeit this probably may be too abstract to call a principle. In that case, I'd rather not have any.

epolanski• 4 years ago

Don’t only write code for the happy scenario.

I always have had problems communicating this to my colleagues, managers and stakeholders.

I remember having this discussion with a stakeholder once when I was a consultant:

PM: "How long would it take to have a page with a table with this payment data and this design?"

Me: "The page you're looking for doesn't exist exactly, it's more complex than that."

PM: "What do you mean?"

Me: "There is a page that maybe, eventually will have this table".

PM: "But I want this"

Me: "Okay, but when the user lands on the page, there is still no data, it is being fetched from our backend service. We need to give the user some feedback and tell him his data is loading".

PM: "Okay, add a spinner or something".

Me: "But that's not enough. What if the server hasn't answered after 5 or 10 or 60 seconds? How would the user react? Should we retry the call? Should we give him some other feedback? What if the response actually contains no data, because for the given filters there are no payments? What if the data is malformed? This may crash the application. What if the user is not authenticated or not authorized for the data? Isn't this an admin-only route? Estimating the table itself is one job, but defining all the requirements and handling all the non-happy-cases or edge cases is a totally different game".

Problem is, explaining this to stakeholders, and sometimes even colleagues that "don't care and just want the task to be over" isn't always simple and the solution is generally "we will fix backend so it sends you always correct data in acceptable times".

And then, you spend much more time fixing these edge cases after you go in prod and it becomes a giant spaghetti ball.

A seasoned and experienced backender very well understands that a (well formed) 200 is just one of possible answers he's gonna give back based on the request and database data, and yet we keep treating the less probable outcome as the only scenario.

bumerangu• 4 years ago

So at the end, it all comes down to "Fail fast" ?

My guiding principles after 20 years of programming (2020)

Related Stories