15 ms·

My guiding principles after 20 years of programming (2020)

505 points by firstSpeaker 5y ago

ur-whale 5y 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.
bullen 5y 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.
kqr 5y 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 5y 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.
- kqr 5y ago
  Gather a bunch of co-workers and lobby for 15 % time! You should absolutely have some time for pet projects at work.
  - andreime 5y ago
    I think it's amazing if one can claim with a straight face people should `absolutely` be paid for pet projects at work.
    - codebje 5y ago
      If we're arguing here that it's a great form of professional development, why would it be a joke to get better at your job, on your job?
      - reitanqild 5y ago
        Furthermore, in some cases I think it is a great idea. I've seen to many "interesting" technlogies being crammed into projects just because devs needed them on the CV. If people can test out everything they want without having to claim that they need it on a project it can save ourselves a lot more than 15% on any project or product that lives for more than a year or two. At work we are still sometimes suffering because of how cool Redux once was.
      - tdrgabi 5y ago
        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.
        bambam3000 5y ago
        this is such a poor analogy
        tdrgabi 5y ago
        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...
- codr7 5y 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 5y 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 5y 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).
- sdfgdf 5y ago
- oohaargh 5y 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 5y 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 5y 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.
  - hackerfromthefu 5y 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 5y 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.
- rablackburn 5y 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 5y ago
    Fake progress bar?
    - rablackburn 5y ago
      Indeed. Or one that doesn’t show progress at all, it just cycles through tips / puns
orlp 5y 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/ 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_ 5y 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.
- kqr 5y 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 5y ago
i_like_robots 5y 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 5y ago
  Readme based development sounds like a great idea!! Thanks.
  - aloisdg 5y ago
    "Doc > Test > Code" is something I can get behind :)
- thejosh 5y 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 5y 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.
beardyw 5y 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 5y 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 5y ago
Does FAANG still ask you to Leetcode after 20+ years of experience?
- yodsanklai 5y ago
  Yes, if you apply for a SWE position.
- Mawr 5y ago
  experience != skill Experience is merely the prerequisite for skill, it doesn't cause it.
- weatherlite 5y ago
  If course, and algo whiteboard sessions. It's even harder for seasoned devs since they graduated ages ago.
Yuioup 5y ago
A great list!
usrbinbash 5y 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 5y 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.
  - usrbinbash 5y 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.
keithalewis 5y 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 5y 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.
  - hackerfromthefu 5y 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 5y 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 5y 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 5y 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 5y 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.
dustinmoris 5y 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
- fullstackchris 5y 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"
  - dustinmoris 5y ago
    My point is take dependencies, just skip the magic ones because they are vile
deleted 5y ago
[deleted]
fullstackchris 5y 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)
- rablackburn 5y 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
  - fullstackchris 5y 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-patterns-the-case-for-one-function-per-file-da68c15826e8 https://chrisfrewin.medium.com/advanced-code-organization-pa...
einpoklum 5y 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.
- hackerfromthefu 5y ago
  Well you can extend the tooling to suit your needs. As Steven Covey says, sharpen the saw.
aa-jv 5y 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 5y ago
  Is every job a social service?
  - aa-jv 5y 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 5y ago
"Pick the right tool for the job" --- exit
- andrewmcwatters 5y ago
  It’s my litmus test for idiots who think they have something useful to say.
janandonly 5y 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.
rvr_ 5y 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 5y 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.
andai 5y 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 https://youtube.com/watch?v=k8gIJOy0c2g
- dgb23 5y 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.
oswamano 5y ago
> Stay clear from hype-driven development. Man i still remember when it felt like a new js framework was coming out every day
Dave3of5 5y 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 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.
- Clubber 5y 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.
GnarfGnarf 5y ago
Excellent rules (57 years). One quibble; I would rate: Security > Maintainability > (...)
ramesh31 5y 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 5y 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 5y 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 5y 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.
MaxMoney 5y ago
ChrisMarshallNY 5y 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.
omginternets 5y 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.
- taeric 5y 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.
  - omginternets 5y 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.
    - taeric 5y ago
      I agree with that. I mainly think it is like most metaphors, and largely used to argue whatever position the debater has. Whatever use it may have, is indeed evaporated as both sides of the debate burn away at it.
- zild3d 5y ago
giantg2 5y ago
My 10 years have given me one principle - make money. I don't want to work like this forever.
conjectures 5y 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 5y 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 5y ago
Lost me at #3
unixhero 5y ago
Inventing on principle: https://www.youtube.com/watch?v=PUv66718DII https://www.youtube.com/watch?v=PUv66718DII Thank you Bret Victor
billti 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago
So at the end, it all comes down to "Fail fast" ?

505 points by firstSpeaker 5y 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.

bullen 5y 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.

kqr 5y 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 5y 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.

kqr 5y ago
Gather a bunch of co-workers and lobby for 15 % time! You should absolutely have some time for pet projects at work.
- andreime 5y ago
  I think it's amazing if one can claim with a straight face people should `absolutely` be paid for pet projects at work.
  - codebje 5y ago
    If we're arguing here that it's a great form of professional development, why would it be a joke to get better at your job, on your job?
    - reitanqild 5y ago
      Furthermore, in some cases I think it is a great idea. I've seen to many "interesting" technlogies being crammed into projects just because devs needed them on the CV. If people can test out everything they want without having to claim that they need it on a project it can save ourselves a lot more than 15% on any project or product that lives for more than a year or two. At work we are still sometimes suffering because of how cool Redux once was.
    - tdrgabi 5y ago
      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.
      - bambam3000 5y ago
        this is such a poor analogy
        tdrgabi 5y ago
        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...
codr7 5y 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 5y 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 5y 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).
sdfgdf 5y ago
oohaargh 5y 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 5y 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 5y 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.
- hackerfromthefu 5y 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 5y 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.

rablackburn 5y 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 5y ago
  Fake progress bar?
  - rablackburn 5y ago
    Indeed. Or one that doesn’t show progress at all, it just cycles through tips / puns

orlp 5y 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/ 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_ 5y 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.
kqr 5y 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 5y ago

i_like_robots 5y 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 5y ago
Readme based development sounds like a great idea!! Thanks.
- aloisdg 5y ago
  "Doc > Test > Code" is something I can get behind :)
thejosh 5y 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 5y 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.

beardyw 5y 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 5y 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 5y ago

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

yodsanklai 5y ago
Yes, if you apply for a SWE position.
Mawr 5y ago
experience != skill Experience is merely the prerequisite for skill, it doesn't cause it.
weatherlite 5y ago
If course, and algo whiteboard sessions. It's even harder for seasoned devs since they graduated ages ago.

Yuioup 5y ago

A great list!

usrbinbash 5y 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 5y 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.
- usrbinbash 5y 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.

keithalewis 5y 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 5y 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.
- hackerfromthefu 5y 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 5y 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 5y 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 5y 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 5y 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.

dustinmoris 5y 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

fullstackchris 5y 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"
- dustinmoris 5y ago
  My point is take dependencies, just skip the magic ones because they are vile

deleted 5y ago

[deleted]

fullstackchris 5y 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)

rablackburn 5y 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
- fullstackchris 5y 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-patterns-the-case-for-one-function-per-file-da68c15826e8 https://chrisfrewin.medium.com/advanced-code-organization-pa...

einpoklum 5y 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.

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

aa-jv 5y 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 5y ago
Is every job a social service?
- aa-jv 5y 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 5y ago

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

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

janandonly 5y 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.

rvr_ 5y 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 5y 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.

andai 5y 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 https://youtube.com/watch?v=k8gIJOy0c2g

dgb23 5y 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.

oswamano 5y ago

> Stay clear from hype-driven development. Man i still remember when it felt like a new js framework was coming out every day

Dave3of5 5y 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 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.

Clubber 5y 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.

GnarfGnarf 5y ago

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

ramesh31 5y 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 5y 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 5y 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 5y 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.

MaxMoney 5y ago

ChrisMarshallNY 5y 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.

omginternets 5y 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.

taeric 5y 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.
- omginternets 5y 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.
  - taeric 5y ago
    I agree with that. I mainly think it is like most metaphors, and largely used to argue whatever position the debater has. Whatever use it may have, is indeed evaporated as both sides of the debate burn away at it.
zild3d 5y ago

giantg2 5y ago

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

conjectures 5y 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 5y 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 5y ago

Lost me at #3

unixhero 5y ago

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

billti 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago

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