15 ms·

Things I Believe About Software Engineering

420 points by turingbook 7y ago

karmakaze 7y ago
> There are many fundamental discoveries in computer science that are yet to be found. Purely in the realm of computer science and has little the no bearing on a software engineering context.
- falcolas 7y ago
  Except when it does. It's not fast, but these findings in CS find their way into general software development. See: Rust, Haskell, Typescript, ML, Ray tracing, and so forth.
einpoklum 7y ago
> Being aligned with teammates on what you're building is more important than building the right thing. So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? Strongly disagree with that. > Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Here I mostly agree. The thing is, that you don't know in advance when these hours are going to happen. Also, sometimes it's 2, sometimes 0 and sometimes 8. > The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use. (Yawn) Indeed...
- _petronius 7y ago
  > So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? Seems like a very unfair restatement of what the author said. I would read that as "it's more important that everyone has a common understanding of what you are building than it is to spend time worrying about whether you have the exactly perfect goal." Or to phrase it another way: if the understanding of the product isn't clear across the whole team, it doesn't matter if any one individual has a bunch of brilliant ideas for/about the product, because you aren't all working towards the same goal.
  - smitty1e 7y ago
    I'd offer that the "alignment" is substantially a function of the management/leadership on display.
    - _petronius 7y ago
      Sure, but hopefully the choice isn't a binary one between "lack of alignment" versus "management/leadership dictates", since that would be evidence of a rather toxic team culture.
  - gwd 7y ago
    > I would read that as "it's more important that everyone has a common understanding of what you are building than it is to spend time worrying about whether you have the exactly perfect goal." The fact is, that unless you have a functioning crystal ball, you don't actually know what the perfect goal is; you only have hazy guesses at best. At some point, extra time spent looking for the perfect goal is wasted, because one hazy guess is no better than the next. It's much better to get something that is well-structured and functioning out the door. If you've done your due diligence, it has as much chance of succeeding (or failing) as the next thing. And to get something well-structured and functional out the door, you need everyone to be working towards the same goal, even if they don't all necessarily agree that that's the perfect goal. There's an argument that this is how ancient divination worked in practice. You don't know whether you should attack from the north, attack from the south, or hunker down and build defenses. You definitely can't do all three. It's much better to pick one and do it boldly than to dither around in indecision. Divination gets everyone fully behind one option; that option may not be the optimal one, but it's certainly better than "do nothing". Which makes me wonder if maybe modern product management would be better with some oracle bones...
  - ojilles 7y ago
    It's also a reflection (or assertion?) that software development largely is a team sport, not an individual one.
  - dadarepublic 7y ago
    This is pretty much how I grokked the point. Having a common vision is critical in team building and in actually building the right/correct/good thing.
- AnthonBerg 7y ago
  > So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? That's misalignment :)
- pfarrell 7y ago
  > So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? That's not alignment. For alignment to happen, everybody should be on the same page. And any party can tank this if they refuse to negotiate. I read this as getting alignment between all parties is something that leads to successful projects and therefore is something that should require attention and effort to make happen. I've ruminated on Jeff Bezos/Amazon's "Disagree and commit" leadership philosophy a bit and think it pertains here. Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly. [0] Where I think "leaders" is a quality of a person's actions, not a job title. [0]: https://www.amazon.jobs/en/principles https://www.amazon.jobs/en/principles
  - pc86 7y ago
    Just make sure you're negotiating the thing you're supposed to negotiate. I've been in meetings where junior or mid-level developers with minimal experience are arguing the merits of the business model with executives. I'm all for asking thoughtful questions but if you have 2 years of experience at a different company in a different industry, saying you don't think Product X is going to make money doesn't really qualify. Likewise, I wish "business folks"/product owners/whatever you want to call them would give a little more leeway on technical decisions to their technical team. We shouldn't be discussing choice of database tech or service architecture with a VP Finance.
    - knightofmars 7y ago
      > I've been in meetings where junior or mid-level developers with minimal experience are arguing the merits of the business model with executives Oof. I'm a big supporter of questions not statements in these situations. I've witnessed people with this behavior, where a person makes claims and argues a point but doesn't have a clear understanding of the situation. They don't realize they're ignorant to a certain portion of information which they need to ask questions to learn about. This happens both with those with minimal experience as well as leadership. Though in the latter case I suspect it is not wanting to be perceived as not having grasp of a situation or being perceived as lacking in knowledge. Which is sad, as people who ask smart questions generally are the best leaders.
- crimsonalucard 7y ago
  >So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? He didn't say cave in. Your first step in the above scenarios is to get buy in and alignment with management and peers. If you cave in then you aren't in alignment. He is saying the latter event is worse.
tr1coder 7y ago
> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Is it possible to improve this by training? For example if I'm productive 2 hours and force myself to be productive 10-30 more minutes each day for a number of days and when I'm comfortable with 2:30 hours of productivity, force myself to be productive for 30 more minutes. Would this eventually lead to 8 productive hours? Or is burnout (or another complication) a more likely outcome? Has anyone tried this?
- brain5ide 7y ago
  How do you define productive so that you could add a time goal to it? Because I read it as "There are on average about two hours of productive in-context work to be done and the other hours are about building that context for those two hours that not often transfer between days." You can't add 10 minutes to that.
- asynch8 7y ago
  I'm guessing this is an average rather than absolute amount every day, and I also don't quite think it's possible to 'force' yourself to be more productive, as being productive is both about how fast you think, how fast you type and how fast you come up with solutions to a problem. No matter how much you force yourself you can't just force yourself not to feel exhausted/restless/depressed or whatever else is effecting your productivity, you sure can alleviate these symptoms, but that's improving your well-being generally rather than forcing yourself to be productive. So it sort of depends what you mean by force, I'm guessing it would just cause you more stress and make you eventually burn out because you're not in reality becoming more productive by focusing more, you're only stressing yourself out further.
- veeralpatel979 7y ago
  For me, I think I can achieve 8 hours if: - I'm working on something I'm interested in - I feel like there's upside for me if the project succeeds - I can work in different places throughout the day, like my desk, my sofa, in another room, etc. Not really possible in an office - It's a quiet area where I won't have people interrupting my flow state - I'm not blocked on things I need to know - I'm working on something that's been de-risked. I know what I need to do and I know how to do it
msla 7y ago
> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. I think it's worse than this: Defining correctness for any nontrivial system to the level of detail required by software is beyond the capabilities of any human or group of humans operating to a deadline. The only way to get there is to pare down the scope such that physically possible things are defined to be out of said scope, such that the system punts and relies on humans to figure it out. This has implications for job automation. > Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill. Attempting to prove yourself wrong is a massively valuable and underutilized skill. If you get a theory, develop a test which the theory is vulnerable to, such that if the test comes out a certain way the theory is disproven, and then run that test. Some people seem unable, or unwilling, to think like that. This has implications for software testing. It has implications for all kinds of testing.
- yetihehe 7y ago
  > If you get a theory, develop a test which the theory is vulnerable to [...] Some people seem unable, or unwilling, to think like that. Because developing that test is often even harder than developing theory itself and developing nontrivial theory requires ALL of your mental effort.
mtrycz2 7y ago
> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have approached their challenges from the point of view of actual engineering, while modern "software engineering" is all about craftsmanship, and just a sprinkle of actual engineering to make ourselves feel good.
- veeralpatel979 7y ago
  Writing "correct" software is possible IMO, but is it worth it? For most applications, is it worth spending several times more time and resources in order to make it "correct"? I don't think so.
  - mristin 7y ago
    I always wondered where this multiplicative factor of "several times" comes from. In my experience, writing correct software was marginally slower than writing sloppy software as long as most thinking is done with a pen & paper. Would you mind to elaborate a bit more?
    - TeMPOraL 7y ago
      I'm guessing: because of cheap labor. Writing correct and/or fast software involves quite a bit of "don't do stupid things" all across the development process. Doing these things right doesn't add much time to development, but one has to first learn how to do these things right. A fresh and inexperienced developer, or the "one year of experience repeated 10 times" person that only worked at "move fast and break things" project isn't going to have this knowledge, but will be cheaper to hire.
    - beagle3 7y ago
      Not OP/GP, but I think it's mostly about the definition of correct. Does it correctly handle every possible sequence of inputs? For the vast majority of software in use today, the answer is "no"; The follow up question is "does it matter?" and (luckily or unluckily) the answer for the vast majority of software in the vast majority of use cases, is "no" as well. But occasionally it does, e.g. https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25 is a famous poster child, and I quote: >>> The failure occurred only when a particular nonstandard sequence of keystrokes was entered on the VT-100 terminal which controlled the PDP-11 computer: an "X" to (erroneously) select 25 MeV photon mode followed by "cursor up", "E" to (correctly) select 25 MeV Electron mode, then "Enter", all within eight seconds Software was not obviously correct or incorrect; In fact, it had been acceptable for an earlier model (which had some hardware protections missing from the newer one). Reaching the incorrect state required the race described above to trigger, which did, in fact, happen in practice a handful of times. You can work very hard to formally prove your implementation, only to find out that the compiler had a bug and makes your software bad. Or the CPU does; Or all the designs are fine, but there's an bit flip due to electro-migration or cosmic rays. Many people consider this "force majeur" - "an act of god" one cannot anticipate, but cosmic rays are in fact an expected -- and hard to avoid -- input to many systems. You are in control of a logical model which you can, with extra work, do (provably) correctly. But that IS, from experiencce, 10x to 100x more expensive, and unless you go for 10x-100x more expensive hardware, reduces and moves the sloppiness factor around, but does not eliminate it.
jwr 7y ago
Couldn't agree more with every point listed. These are fantastic points. I do not know the author, but reading these points makes me suspect he/she is an experienced software engineer that has been doing this for many years now. I expect that especially his first point (about being humble in the face of software systems complexity) will provoke many hubris-filled comments. I fully agree with the author: we are incapable of building complex and correct software systems. This is why I am afraid of the hype behind self-driving vehicles.
- barrkel 7y ago
  I have a different expectation of correctness; absolute correctness is impossible, in practice correctness is not a binary condition. Even if something provably executes correctly according to spec, the spec may be wrong (and probably is, since everything interfaces with humans eventually). Everything is in a process of becoming; 100% correctness is not achievable, but it's not desirable either - it costs too much; it just needs to be better than the next best alternative.
  - makach 7y ago
    Even with 100% correctness, your solution still has the capacity to fail spectacularly. The universe is infinite in its desire to mess with your expectations and assumptions of what correctness is! Oh, you thought that was 100% correct? Well, have a look: A platypus.
  - AstralStorm 7y ago
    The proper goal is robustness. It is either achieved via clear indication of failure and guidance on alternative solutions - so that the user can handle it. Or by actually failing gracefully and handling as many error conditions in an always reasonable way. Usually letting user handle it is more general as long as the failures are rare enough. Internal correctness is perfectly achievable though. External (correct spec) is not. There are always some unhandled conditions, due to hardware or external component failures...
  - bregma 7y ago
    Wow, that's along-winded way of saying "perfect is the enemy of good enough".
cryptica 7y ago
Based on the title, I was especting yet another opinionated story written by a successful outlier littered with biases, but actually every point resonated with me. Maybe this article illustrates the difference between sharing knowledge and sharing wisdom. Knowledge can be divisive because it's often communicated through rigid (black or white) statements and founded on outlier experiences but wisdom is generally not divisive; wisdom usually doesn't get people as excited but it's also harder to refute; wisdom is knowledge without the bias. There are plenty of extremely clever (and extremely biased) developers, but very few wise ones. I tend to think that upvote/downvote mechanisms (Like on Reddit and HN) are somewhat of a threat to the sharing of wisdom because wise ideas don't create that dopamine rush which clever ideas do (they don't trigger the strong feelings required for upvote/downvote). Wisdom is rarely surprising or controversial. Even discussing the idea of wisdom seems to be taboo. As if it's some kind of outdated concept; but the irony is that it's more relevant now than ever.
jingw222 7y ago
Being perfectly aligned with teammates on everything but ending up with a totally differently or straight wrong result. How do you justify that? Otherwise I'm with OP.
galawa 7y ago
i have a gambling strategy that will help beat Roulette, the strategy work best for land based Casino on roulette game and the strategy does not work for online casino. i am selling my gambling strategy for only $100,000 . if you are interested to buy by holy grail gambling strategy that beat roulette then let me know by sending message to my email advanotech@gmail.com
BigJono 7y ago
> The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry. This is an interesting one. I first took it to mean 'current testing practices are inadequate', which isn't an extreme opinion, and one I bet 99% of HN agrees with. It's 'common wisdom' that teams should be doing more testing, TDD, etc. But now that I read it again, it's specifically saying that current testing practices are 'ineffective', not 'inadequate', which would indicate we should be doing less or even none of it. 'ineffective' to me means worse than nothing, since testing, like anything, has a cost. (time wasted, more code to maintain, lower morale etc) I'm not sure which the author meant. But I do think the latter is a hot take, and I get the feeling I'm in the minority in agreeing with it. I'm reminded of this PG quote (obviously written a while ago): "Indeed, these statistics about Cobol or Java being the most popular language can be misleading. What we ought to look at, if we want to know what tools are best, is what hackers choose when they can choose freely-- that is, in projects of their own. When you ask that question, you find that open source operating systems already have a dominant market share, and the number one language is probably Perl." If I think about what I've written unit tests for at home, that'd be a bunch of maths-y stuff that I was having trouble debugging, and a few functions here and there that I consider 'tricky' and want a bit of extra peace of mind for. When I'm building web apps at home though, like I always do at work, how much of it do I write unit tests for? Zero. I can't quantify why. I just know intrinsically that they're useless and it's a waste of time. I just know that 95% of my code works and I know what the 5% I'm unsure about is and what manual testing or browser testing I need to do to clarify it. If anyone on my team at work ever said that, everyone would look at them like they just took a shit on the carpet (including me, because I'm happy to smile and nod for the right salary). Then there's this, from the same essay: "One difference I've noticed between great hackers and smart people in general is that hackers are more politically incorrect. To the extent there is a secret handshake among good hackers, it's when they know one another well enough to express opinions that would get them stoned to death by the general public. And I can see why political incorrectness would be a useful quality in programming. Programs are very complex and, at least in the hands of good programmers, very fluid. In such situations it's helpful to have a habit of questioning assumptions." I definitely know a few coders I've worked with who I'd be comfortable raising my views on testing with. We might differ on the details (I quite like browser tests, don't find a lot of value in snapshot testing most of the time, we might unit test a different tiny subset of the app etc), but by and large we'd agree that most common testing is a crock. And coincidentally, they're all the devs that I think write fantastic code, and that I'd happily build a startup with. Anyway, that's my Thing I Believe About Software Engineering, with a bit more clarification than OP's ones.
astura 7y ago
>Being aligned with teammates on what you're building is more important than building the right thing. Goodness this is incredibly naive. It can only be true only if youre working without customers or stakeholders and who the hell works that way other than hobbyists and startups that are indiscriminately wasting other people's money? The vast majority of software I've written (I'm outside the valley) is written for actual paying customers, and it must be "the right thing," ie, exactly what they paid you to build. Beyond that, if you're, for example, writing an emulator and the emulator works different than the system it's emulating that's a failure no matter how "aligned" your team is. Nobody will buy it and nobody would even use if you gave it away.
- C4stor 7y ago
  Except that for a lot of developers, "the right thing" has nothing to do with what customers want, but rather with language used, libraries used, CI/CD setup, monitoring active... So many technical aspects that sometimes have nothing to do with the customer wants. And that's where being aligned makes sense.
- sime2009 7y ago
  > Goodness this is incredibly naive. Actually it demonstrates hard earned wisdom. A team which isn't aligned will only produce a mess regardless of whether their end goal was the right thing. An aligned team may miss the target but they will be in a position to correct themselves and pursue the target.
loxs 7y ago
> The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use. For me this is not true. The type system has a bigger impact on me. If I use a language with static types + IDE, I am quite productive even while chronically not getting enough sleep (currently looking after a newborn). Probably much more productive compared to writing in a dynamic language while getting enough sleep. And of course, that does not mean that sleep is not a huge factor. It most definitely is.
andruby 7y ago
> Being aligned with teammates on what you're building is more important than building the right thing. I would write this as: Building the right thing wrong is more important than building the wrong thing right. And I firmly believe that agreeing on _what_ you are builing is more important than _how_ you are building it. Mainly because it is easier to change the _how_ than it is to change the _what_.
- karmakaze 7y ago
  > Building the right thing wrong is more important than building the wrong thing right. I entirely agree with this, but don't think that's what the original point was getting at. > And I firmly believe that agreeing on _what_ you are building is more important than _how_ you are building it. Mainly because it is easier to change the _how_ than it is to change the _what_. This seems like it should be true. In practice, I've found that the _how_ is the part that gets embedded in the wet-ware of people/companies and is the hardest to change. Given an application written in a language with some framework, some datastore, deployed to some cloud, it's actually exceedingly easy to make another that follows that pattern and does a completely different business function. Much more challenging would be to change those parts of an application and keep it doing the same thing.
- emmanueloga_ 7y ago
  I read it as: "Build consensus before you start building any specific implementation". ... the idea being that it is better for a team to collaborate on a compromise solution than any given person pushing into their pet solution because they "know better".
EnderMB 7y ago
I clicked this expecting an overly opinionated list on how to do things the right way, but came away agreeing with nearly everything said. > Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. This is the one point I somewhat disagree with, and it leads to one of the things I believe about SE - it's all about perceived risk. Mission-critical systems work well because the risk is well-defined, and it's usually "people will die". In business, managers are happy to break rules when the perceived risk of it biting them in the ass is low. Small budget? Skip the tests, click around on deploy to see if it works, and ship it. Not enough time? Deliver a minimal product and build the rest later when we have the budget. There are two examples I often use for this - Panera Bread and Pipdig. The former leaked millions of customer records, ignored the press for a few days, and got off with zero consequences. Pipdig did even worse, they did backdoors and DDoS code to attack competitors in their WP themes/plugins, and when called out they lied, hid the evidence, and then went back to selling themes to unsuspecting bloggers with zero consequences. Both sides likely knew what they were doing was wrong, but the risk of getting caught was minimal, so why not break the rules? It probably saved them a ton of money in the long run. > Being aligned with teammates on what you're building is more important than building the right thing. I've no idea why so many of you are up in arms about this. It isn't about bowing to managers, or being a punching bag for others. It's about making concessions as a group to define what you need to build, and the best way of doing it. > Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. I'd stretch this to say that "on average". Some days I'll get 30 minutes of stuff done, some days I'll fly through work for a solid 8 hours. > Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill. This is so true it hurts. I'm currently working on a project in an agile structure, and it's going like many agile projects I've worked on in the past. Agile is used as a buzzword for "fuck planning, just write user stories and be done with it", all while team mates bitch and moan about spending too long in "planning" meetings. The second we took the time to actually have these meetings and plan out our backlog, we made key decisions and discoveries about how things work, what edge cases we need to think about, what doesn't work from a user perspective, etc. > How kind your teammates are has a larger impact on your effectiveness than the programming language you use. Over the years, I've always believed that empathy is the best skill you can have in software, and that is often paired together with kindness. An empathetic team is often a kind team, and when empathy is a core part of a team it highlights areas where certain stakeholders don't share that trait.
neilwilson 7y ago
I'm with Dijkstra "Our intellectual powers are rather geared to master static relations and ... our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible." As Systems Engineers we're probably better than 99% of the population at visualising the dynamics of the system, and even then we're still pretty bad at it. Humility in the face of this human limitation helps enormously I find.
- prox 7y ago
  I really like this quote, and humility in this case helps to more clearly view the problem (and hopefully solve it adequately)
- crimsonalucard 7y ago
  Humility should not preclude aggressive problem solving towards eliminating the gap. Be humble and be open to the possibility that this problem can be utterly destroyed. Have you heard of functional programming?
  - skywhopper 7y ago
    The list of "things I believe" the OP cited mentions functional programming as a fundamental belief as well, because it "eliminates side effects" and doesn't "mutate state". And yet, these traits give us little or no help in troubleshooting problems in distributed computer systems, where side effects are inherent and state is in constant flux. Oh sure, to within the CAP theorem, you can keep your data store relatively consistent and immutable, but that's only helpful so long as all the rest of your infrastructure is infallible. Which it isn't.
    - smilliken 7y ago
      It's not about eliminating effects! It's about controlling them. A program that had no effect would be perfectly useless. In distributed systems, it's important to be very intentional about effects, instead of letting them creep into any part of your program.
bartread 7y ago
> Being aligned with teammates on what you're building is more important than building the right thing. I don't buy this. I'm not sure these two things should be placed in opposition (or at least tension) in this way. It makes for a nice soundbite but I don't think it withstands scrutiny. I've seen and worked in teams where alignment was great and we all worked really well together but, at the end of it all, nobody bought the damn product. I.e., we didn't build the right thing. Let's not kid ourselves: aligning and working well together to build the wrong thing is somewhat pointless (granted, you might learn some useful lessons along the way). Now, if you take that team and then assign them to build the right thing you have something really powerful.
- mic47 7y ago
  I read it more like this: If you are building right thing, but you are not aligned, then you will not build the right thing and you will fail. But if you are aligned, it's easier to steer the ship closer to the right thing.
  - k__ 7y ago
    Sure. But I've seen too many dev departments building crap over and over again and feeling pretty good about themselves the whole time.
    - KnobbleMcKnees 7y ago
      > building crap over and over again and feeling pretty good about themselves I'm triggered
    - 6510 7y ago
      I wonder how few wrote something that in their own opinion wasn't crap and did something impressive.
      - k__ 7y ago
        Technically maybe.
EugeneOZ 7y ago
> The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry. It's not tests' fault that programmers are lazy and write tests not for every function, or write unit tests without integration tests or write vice versa. Whole article is just low-quality whining.
- cixter 7y ago
  woosh
lordnacho 7y ago
> Most measures of success are almost entirely uncorrelated with merit. This is life in general, no? Aside from maybe professional sports, where it's forced to be that way by design.
hliyan 7y ago
By some remarkable coincidence, @JanStette's version of this (1) and mine (2) have a lot of overlap. Maybe we should all write a version of this and see if common themes emerge. Jan and I clearly agree on coding, design and testing, for example. 1. https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d14e2b https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1... 2. http://zen.lk/2019/08/18/Things-I-believe/ http://zen.lk/2019/08/18/Things-I-believe/
classified 7y ago
Thank [insert relevant deity] I'm not a reasonable person, so I can afford to agree with all of the author's points. Especially the one about testing. And if that applies to you: Kick those amphetamines and get more sleep instead.
unnouinceput 7y ago
"<Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.>" You can say this about any tech field. Heck you can say this about social domains as well. And yet world marches over with progress being made. "<Being aligned with teammates on what you're building is more important than building the right thing.>" Because yeah, building the wrong thing was always good and had nothing to do with economic failures, right? Tell this also to NASA teams that build the moon race, is littered with teams doing different stuff and not being aligned. My favorite story for that is the one about how they made the suit. "<There are many fundamental discoveries in computer science that are yet to be found."> There are many fundamental discoveries in all fields that are yet to be found, CS is no more special then Psychology for example, it only pays better these days. "<Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours."> Peak productivity depends on each individual and within each individual there are seasons. I can be productive at nights or during day time, and when I am productive during certain hours for the life of me I would not be able to be productive on other hours. Procrastination is perception of individuals during their non-productive hours. "<Most measures of success are almost entirely uncorrelated with merit."> Finally, the single statement in this otherwise useless article that I can agree with. "<Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill."> That depends on what your education/how your parents raised you. As for how much value this has in current society, well just ask Trump (he's still a billionaire). Also, in that regard see previous point. "<The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry."> Actually the standards are quite high, you should've seen them 40 years ago when Ford preferred to allocate 200M USD for paying victims than rather improve its safety when building the chassis, because that would've eaten their profits ten fold. <"How kind your teammates are has a larger impact on your effectiveness than the programming language you use."> Become freelancer, be your own boss and you couldn't care less about teammates. One man show where you call all the shots is awesome. "<The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use."> This point goes hand in hand with above one about productivity, it all boils down to each individual.
karmakaze 7y ago
> Being aligned with teammates on what you're building is more important than building the right thing. It depends. If iterations are quick and the current direction is roughly on the path to finding the right thing yes, otherwise no unless you are choosing to redefine software engineering.
jmull 7y ago
> Most measures of success are almost entirely uncorrelated with merit. A more important and useful thing to understand is that merit is measured by rules that bubble out of social systems. A mistake you can make is to believe the the rules of merit that you believe are the same ones others believe, that the ones they state are the same ones they actually believe, that the rules don't depend on context, etc. It's hard for people to accept this because we're taught that merit is an inherent quality, we may internalize the rules of merit we learn, treat them as constants, and then build our self-images based on those rules. (I'm not suggesting to give up on the idea of merit altogether, but you'll do better to think of it as something you achieve for personal satisfaction and not necessarily expect external rewards.) BTW, the rules of success (beyond the most basic stuff) are also social constructs, but they are different than the rules of merit. It's a mistake to expect them to necessarily be harmonious or consistent.
- crimsonalucard 7y ago
  I don't agree with 'most.' Our schooling and educational systems are very merit based. One could say that in the work place, success is uncorrelated with merit.
  - NohatCoder 7y ago
    School and workplace is just an example of two very different merit systems. One is not inherently more right than the other.
    - crimsonalucard 7y ago
      Never said one is more right. But merit in the workplace is not quantitatively measured in any form.
  - oarabbus_ 7y ago
    >One could say that in the work place, success is uncorrelated with merit. Do you truly believe this? In my career experience, success is highly correlated with merit. Sure, I have seen plenty of incompetence at high positions, and I've seen brilliant people who received little success in their careers. But overall, I'd say the correlation is very high.
karmakaze 7y ago
> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Pair programming can easily double that and the low productivity periods are not nearly as low.
- bartread 7y ago
  > Pair programming can easily double that and the low productivity periods are not nearly as low. Pfft. Prove it. People are very different and work best in different ways. I don't mind pair programming for specific reasons but as a the "normal" way of working? You can keep it. Pair programming performed relentlessly selects for certain personality types. I, for example, didn't get into programming because I wanted to sit around talking all day. Far from it. Programming is a creative endeavour, kind of like songwriting. Some people are great solo songwriters, some people work well together, people often struggle to cross that divide and, even if they collaborate well, may struggle to collaborate well with everyone. I can work effectively in a team but under most circumstances I cannot program at my best with somebody hovering around or buzzing in my ear all time. And, believe me, I am by no means unusual in that regard. Mandatory pair programming is one of those things that, I think, seems like a good idea to third rate management who don't want to take the time to understand how the people on their teams can work together most effectively.
  - karmakaze 7y ago
    All good points and I was of the same opinion before I underwent almost 2 years of mostly pairing. My takeaways: People are different. The core bunch came from Pivotal which performed pair-programming interviews so were self selected. That accounted for about half the engineering staff so the other half didn't undergo this process. I myself have always been a solo developer so pairing was very unnatural at first and I didn't pair well with everyone. We rotated pairs every week (sometimes two) so that wasn't a big problem. There are times when solitary deep thought is useful and breaks for that activity could be taken at will while the other pair works on maintenance tasks etc. Most of the time the work isn't of this type and more often less complex requiring light whiteboarding or on-screen prototyping which both work well when pairing. The style of code that comes out of pairing tends to be more plain than when working solo. There is incremental progress in both implementations and design refinements when pairing. When working solo there tends to be grander designs with a moment where it all comes together or not. I enjoy the latter but find the former higher by average throughput. Pairing tends to eliminate more of the 'might need soon' or 'will need in the future anyway' implementations. After pairing with someone a few times, verbal communication becomes very terse and fluid. An unexpected benefit was the ability to immediately resume context after interruptions or breaks. The biggest advantage of pair-programming that doesn't get mentioned much is the organic spread of good practices and conventions. With approximately 20 devs it's not really worth writing and maintaining standards documentation and conventions for handing new cases that keep appearing. With rotating pairs this discovery of what works well and normalization upon it is natural. Minor tips and tricks aside from the source code can also be invaluable power-ups when learned by others. Pair programming isn't about maximizing 'your own productivity' it's about maximizing the productivity, quality, and consistency across all dev teams. Within that period we also tried full-stack dev pairing. This was much more challenging and didn't work nearly as well. We didn't stick with it long enough to know if it could become more beneficial because basically people self-selected into front or back-end development and liked it that way. These are my findings from being both a solo and pair-programming developer. If you're curious and have an opportunity I highly recommend trying to stick with it for a while and see what your findings are.
AJRF 7y ago
> "Read the classics. So many “new” ideas in software development have actually been around for decades." From the original post that inspired this post: https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d14e2b https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1... What would HN say are the "classics"?
- dschadd 7y ago
  Pragmatic Programmer and Code Complete are usually mentioned as classic programmer text books. I own both and have probably read 10 pages between the 2 books.
  - boring_twenties 7y ago
    I haven't read Code Complete but I did flip it open to a random page around halfway through the book, and was treated to a page-long explanation about the fact that conditions in loops aren't constantly being evaluated, but only once at the top of each loop. I think it's reasonable to simply assume the entire book is bullshit after that.
- stronglikedan 7y ago
  I don't know if it's a "classic", but I recently picked up a copy of Wicked Problems, Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms [0] after reading through another HN thread on good software dev books. I haven't cracked it open yet though. [0] https://books.google.com/books/about/Wicked_Problems_Righteous_Solutions.html https://books.google.com/books/about/Wicked_Problems_Righteo...
  - varrock 7y ago
    Can you link the HN thread about good software development books?
DBYCZ 7y ago
His last point is my favorite, I feel useless at work if I don't get decent sleep. He should append working out and going for walks to that as well.
antirez 7y ago
> There are many fundamental discoveries in computer science that are yet to be found. That's a strange claim. It could be, but there are large evidences that we discover most of the fundamental things immediately up to the 80s, and then the other improvements are kinda really incremental, a program from 1970 is not alien today. Technology of computing progressed a lot more than CS itself, a computer of 1970 kinda is alien, and a toy.
- wry_discontent 7y ago
  Your description of how things are is exactly how Thomas Kuhn describes the process of "Normal Science" in The Structure of Scientific Revolutions. Cracks in our understanding grow, and patchwork theories are put around those contradictions, but eventually the dam breaks and a scientific revolution reshapes the way we think about a subject.
- jdance 7y ago
  I don't think we will sit at our computers writing code in the same way a hundred years from now. It just feels very inefficient to me, it's a good abstraction for now but better will come, new paradigms that probably look radically different. I personally would find the opposite claim rather strange :)
pmiller2 7y ago
Here is my (unpopular? original?) opinion about software engineering: software engineering is more like writing a novel than building a bridge. Bridges are fairly well understood, and the parameters necessary to build them successfully can be approximated very closely once it’s decided what materials to use. Software will surprise you, in the sense of “no battle plan survives contact with the enemy.” You will have bad data in prod. Users will do unexpected things. You won’t always be able to reach S3. And, this is all true even assuming the software is written perfectly to spec. Knuth has famously said he thinks reusable code isn’t all it’s cracked up to be. It’s re-editable code that we ought to all be striving for. There are two aspects to this. First, how often do you get to write entirely new code inside a mature software project? Not often, I would wager, so why not make the job as easy on future you as possible? Second, re-editable code needs to be understood before it can be edited to extend it. This means we need to write code for humans to read, and computers, only incidentally, to execute (I think EWD might have said something to that effect).
- kikimora 7y ago
  > You will have bad data in prod. Users will do unexpected things. You won’t always be able to reach S3. And, this is all true even assuming the software is written perfectly to spec. Surprisingly this nonsense happens in a discrete setting where we can (in theory, of course) enumerate all possible inputs. Again surprisingly we cannot find effective way to automagically partition input space into equivalence classes to assist us in testing. Novel works in conjunction with our brains and it is not surprising that there are no definitive rules or “good novel equation”. But programs implement defined algorithms and super predictable. Yet creating them feels like writing a novel. I agree with your statement but at the same time it feels wrong that we find ourselves in such position.
l0b0 7y ago
> Being aligned with teammates on what you're building is more important than building the right thing. It's important to define the terms here. Does "important" mean important to you or the company? I could understand the former, but how are you ever going to build the "right thing" if you can't agree as a team what you're building?

420 points by turingbook 7y ago

> There are many fundamental discoveries in computer science that are yet to be found. Purely in the realm of computer science and has little the no bearing on a software engineering context.

falcolas 7y ago
Except when it does. It's not fast, but these findings in CS find their way into general software development. See: Rust, Haskell, Typescript, ML, Ray tracing, and so forth.

einpoklum 7y ago

> Being aligned with teammates on what you're building is more important than building the right thing. So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? Strongly disagree with that. > Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Here I mostly agree. The thing is, that you don't know in advance when these hours are going to happen. Also, sometimes it's 2, sometimes 0 and sometimes 8. > The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use. (Yawn) Indeed...

_petronius 7y ago
> So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? Seems like a very unfair restatement of what the author said. I would read that as "it's more important that everyone has a common understanding of what you are building than it is to spend time worrying about whether you have the exactly perfect goal." Or to phrase it another way: if the understanding of the product isn't clear across the whole team, it doesn't matter if any one individual has a bunch of brilliant ideas for/about the product, because you aren't all working towards the same goal.
- smitty1e 7y ago
  I'd offer that the "alignment" is substantially a function of the management/leadership on display.
  - _petronius 7y ago
    Sure, but hopefully the choice isn't a binary one between "lack of alignment" versus "management/leadership dictates", since that would be evidence of a rather toxic team culture.
- gwd 7y ago
  > I would read that as "it's more important that everyone has a common understanding of what you are building than it is to spend time worrying about whether you have the exactly perfect goal." The fact is, that unless you have a functioning crystal ball, you don't actually know what the perfect goal is; you only have hazy guesses at best. At some point, extra time spent looking for the perfect goal is wasted, because one hazy guess is no better than the next. It's much better to get something that is well-structured and functioning out the door. If you've done your due diligence, it has as much chance of succeeding (or failing) as the next thing. And to get something well-structured and functional out the door, you need everyone to be working towards the same goal, even if they don't all necessarily agree that that's the perfect goal. There's an argument that this is how ancient divination worked in practice. You don't know whether you should attack from the north, attack from the south, or hunker down and build defenses. You definitely can't do all three. It's much better to pick one and do it boldly than to dither around in indecision. Divination gets everyone fully behind one option; that option may not be the optimal one, but it's certainly better than "do nothing". Which makes me wonder if maybe modern product management would be better with some oracle bones...
- ojilles 7y ago
  It's also a reflection (or assertion?) that software development largely is a team sport, not an individual one.
- dadarepublic 7y ago
  This is pretty much how I grokked the point. Having a common vision is critical in team building and in actually building the right/correct/good thing.
AnthonBerg 7y ago
> So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? That's misalignment :)
pfarrell 7y ago
> So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? That's not alignment. For alignment to happen, everybody should be on the same page. And any party can tank this if they refuse to negotiate. I read this as getting alignment between all parties is something that leads to successful projects and therefore is something that should require attention and effort to make happen. I've ruminated on Jeff Bezos/Amazon's "Disagree and commit" leadership philosophy a bit and think it pertains here. Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly. [0] Where I think "leaders" is a quality of a person's actions, not a job title. [0]: https://www.amazon.jobs/en/principles https://www.amazon.jobs/en/principles
- pc86 7y ago
  Just make sure you're negotiating the thing you're supposed to negotiate. I've been in meetings where junior or mid-level developers with minimal experience are arguing the merits of the business model with executives. I'm all for asking thoughtful questions but if you have 2 years of experience at a different company in a different industry, saying you don't think Product X is going to make money doesn't really qualify. Likewise, I wish "business folks"/product owners/whatever you want to call them would give a little more leeway on technical decisions to their technical team. We shouldn't be discussing choice of database tech or service architecture with a VP Finance.
  - knightofmars 7y ago
    > I've been in meetings where junior or mid-level developers with minimal experience are arguing the merits of the business model with executives Oof. I'm a big supporter of questions not statements in these situations. I've witnessed people with this behavior, where a person makes claims and argues a point but doesn't have a clear understanding of the situation. They don't realize they're ignorant to a certain portion of information which they need to ask questions to learn about. This happens both with those with minimal experience as well as leadership. Though in the latter case I suspect it is not wanting to be perceived as not having grasp of a situation or being perceived as lacking in knowledge. Which is sad, as people who ask smart questions generally are the best leaders.
crimsonalucard 7y ago
>So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? He didn't say cave in. Your first step in the above scenarios is to get buy in and alignment with management and peers. If you cave in then you aren't in alignment. He is saying the latter event is worse.

tr1coder 7y ago

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Is it possible to improve this by training? For example if I'm productive 2 hours and force myself to be productive 10-30 more minutes each day for a number of days and when I'm comfortable with 2:30 hours of productivity, force myself to be productive for 30 more minutes. Would this eventually lead to 8 productive hours? Or is burnout (or another complication) a more likely outcome? Has anyone tried this?

brain5ide 7y ago
How do you define productive so that you could add a time goal to it? Because I read it as "There are on average about two hours of productive in-context work to be done and the other hours are about building that context for those two hours that not often transfer between days." You can't add 10 minutes to that.
asynch8 7y ago
I'm guessing this is an average rather than absolute amount every day, and I also don't quite think it's possible to 'force' yourself to be more productive, as being productive is both about how fast you think, how fast you type and how fast you come up with solutions to a problem. No matter how much you force yourself you can't just force yourself not to feel exhausted/restless/depressed or whatever else is effecting your productivity, you sure can alleviate these symptoms, but that's improving your well-being generally rather than forcing yourself to be productive. So it sort of depends what you mean by force, I'm guessing it would just cause you more stress and make you eventually burn out because you're not in reality becoming more productive by focusing more, you're only stressing yourself out further.
veeralpatel979 7y ago
For me, I think I can achieve 8 hours if: - I'm working on something I'm interested in - I feel like there's upside for me if the project succeeds - I can work in different places throughout the day, like my desk, my sofa, in another room, etc. Not really possible in an office - It's a quiet area where I won't have people interrupting my flow state - I'm not blocked on things I need to know - I'm working on something that's been de-risked. I know what I need to do and I know how to do it

msla 7y ago

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. I think it's worse than this: Defining correctness for any nontrivial system to the level of detail required by software is beyond the capabilities of any human or group of humans operating to a deadline. The only way to get there is to pare down the scope such that physically possible things are defined to be out of said scope, such that the system punts and relies on humans to figure it out. This has implications for job automation. > Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill. Attempting to prove yourself wrong is a massively valuable and underutilized skill. If you get a theory, develop a test which the theory is vulnerable to, such that if the test comes out a certain way the theory is disproven, and then run that test. Some people seem unable, or unwilling, to think like that. This has implications for software testing. It has implications for all kinds of testing.

yetihehe 7y ago
> If you get a theory, develop a test which the theory is vulnerable to [...] Some people seem unable, or unwilling, to think like that. Because developing that test is often even harder than developing theory itself and developing nontrivial theory requires ALL of your mental effort.

mtrycz2 7y ago

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have approached their challenges from the point of view of actual engineering, while modern "software engineering" is all about craftsmanship, and just a sprinkle of actual engineering to make ourselves feel good.

veeralpatel979 7y ago
Writing "correct" software is possible IMO, but is it worth it? For most applications, is it worth spending several times more time and resources in order to make it "correct"? I don't think so.
- mristin 7y ago
  I always wondered where this multiplicative factor of "several times" comes from. In my experience, writing correct software was marginally slower than writing sloppy software as long as most thinking is done with a pen & paper. Would you mind to elaborate a bit more?
  - TeMPOraL 7y ago
    I'm guessing: because of cheap labor. Writing correct and/or fast software involves quite a bit of "don't do stupid things" all across the development process. Doing these things right doesn't add much time to development, but one has to first learn how to do these things right. A fresh and inexperienced developer, or the "one year of experience repeated 10 times" person that only worked at "move fast and break things" project isn't going to have this knowledge, but will be cheaper to hire.
  - beagle3 7y ago
    Not OP/GP, but I think it's mostly about the definition of correct. Does it correctly handle every possible sequence of inputs? For the vast majority of software in use today, the answer is "no"; The follow up question is "does it matter?" and (luckily or unluckily) the answer for the vast majority of software in the vast majority of use cases, is "no" as well. But occasionally it does, e.g. https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25 is a famous poster child, and I quote: >>> The failure occurred only when a particular nonstandard sequence of keystrokes was entered on the VT-100 terminal which controlled the PDP-11 computer: an "X" to (erroneously) select 25 MeV photon mode followed by "cursor up", "E" to (correctly) select 25 MeV Electron mode, then "Enter", all within eight seconds Software was not obviously correct or incorrect; In fact, it had been acceptable for an earlier model (which had some hardware protections missing from the newer one). Reaching the incorrect state required the race described above to trigger, which did, in fact, happen in practice a handful of times. You can work very hard to formally prove your implementation, only to find out that the compiler had a bug and makes your software bad. Or the CPU does; Or all the designs are fine, but there's an bit flip due to electro-migration or cosmic rays. Many people consider this "force majeur" - "an act of god" one cannot anticipate, but cosmic rays are in fact an expected -- and hard to avoid -- input to many systems. You are in control of a logical model which you can, with extra work, do (provably) correctly. But that IS, from experiencce, 10x to 100x more expensive, and unless you go for 10x-100x more expensive hardware, reduces and moves the sloppiness factor around, but does not eliminate it.

jwr 7y ago

Couldn't agree more with every point listed. These are fantastic points. I do not know the author, but reading these points makes me suspect he/she is an experienced software engineer that has been doing this for many years now. I expect that especially his first point (about being humble in the face of software systems complexity) will provoke many hubris-filled comments. I fully agree with the author: we are incapable of building complex and correct software systems. This is why I am afraid of the hype behind self-driving vehicles.

barrkel 7y ago
I have a different expectation of correctness; absolute correctness is impossible, in practice correctness is not a binary condition. Even if something provably executes correctly according to spec, the spec may be wrong (and probably is, since everything interfaces with humans eventually). Everything is in a process of becoming; 100% correctness is not achievable, but it's not desirable either - it costs too much; it just needs to be better than the next best alternative.
- makach 7y ago
  Even with 100% correctness, your solution still has the capacity to fail spectacularly. The universe is infinite in its desire to mess with your expectations and assumptions of what correctness is! Oh, you thought that was 100% correct? Well, have a look: A platypus.
- AstralStorm 7y ago
  The proper goal is robustness. It is either achieved via clear indication of failure and guidance on alternative solutions - so that the user can handle it. Or by actually failing gracefully and handling as many error conditions in an always reasonable way. Usually letting user handle it is more general as long as the failures are rare enough. Internal correctness is perfectly achievable though. External (correct spec) is not. There are always some unhandled conditions, due to hardware or external component failures...
- bregma 7y ago
  Wow, that's along-winded way of saying "perfect is the enemy of good enough".

cryptica 7y ago

Based on the title, I was especting yet another opinionated story written by a successful outlier littered with biases, but actually every point resonated with me. Maybe this article illustrates the difference between sharing knowledge and sharing wisdom. Knowledge can be divisive because it's often communicated through rigid (black or white) statements and founded on outlier experiences but wisdom is generally not divisive; wisdom usually doesn't get people as excited but it's also harder to refute; wisdom is knowledge without the bias. There are plenty of extremely clever (and extremely biased) developers, but very few wise ones. I tend to think that upvote/downvote mechanisms (Like on Reddit and HN) are somewhat of a threat to the sharing of wisdom because wise ideas don't create that dopamine rush which clever ideas do (they don't trigger the strong feelings required for upvote/downvote). Wisdom is rarely surprising or controversial. Even discussing the idea of wisdom seems to be taboo. As if it's some kind of outdated concept; but the irony is that it's more relevant now than ever.

jingw222 7y ago

Being perfectly aligned with teammates on everything but ending up with a totally differently or straight wrong result. How do you justify that? Otherwise I'm with OP.

galawa 7y ago

i have a gambling strategy that will help beat Roulette, the strategy work best for land based Casino on roulette game and the strategy does not work for online casino. i am selling my gambling strategy for only $100,000 . if you are interested to buy by holy grail gambling strategy that beat roulette then let me know by sending message to my email advanotech@gmail.com

BigJono 7y ago

> The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry. This is an interesting one. I first took it to mean 'current testing practices are inadequate', which isn't an extreme opinion, and one I bet 99% of HN agrees with. It's 'common wisdom' that teams should be doing more testing, TDD, etc. But now that I read it again, it's specifically saying that current testing practices are 'ineffective', not 'inadequate', which would indicate we should be doing less or even none of it. 'ineffective' to me means worse than nothing, since testing, like anything, has a cost. (time wasted, more code to maintain, lower morale etc) I'm not sure which the author meant. But I do think the latter is a hot take, and I get the feeling I'm in the minority in agreeing with it. I'm reminded of this PG quote (obviously written a while ago): "Indeed, these statistics about Cobol or Java being the most popular language can be misleading. What we ought to look at, if we want to know what tools are best, is what hackers choose when they can choose freely-- that is, in projects of their own. When you ask that question, you find that open source operating systems already have a dominant market share, and the number one language is probably Perl." If I think about what I've written unit tests for at home, that'd be a bunch of maths-y stuff that I was having trouble debugging, and a few functions here and there that I consider 'tricky' and want a bit of extra peace of mind for. When I'm building web apps at home though, like I always do at work, how much of it do I write unit tests for? Zero. I can't quantify why. I just know intrinsically that they're useless and it's a waste of time. I just know that 95% of my code works and I know what the 5% I'm unsure about is and what manual testing or browser testing I need to do to clarify it. If anyone on my team at work ever said that, everyone would look at them like they just took a shit on the carpet (including me, because I'm happy to smile and nod for the right salary). Then there's this, from the same essay: "One difference I've noticed between great hackers and smart people in general is that hackers are more politically incorrect. To the extent there is a secret handshake among good hackers, it's when they know one another well enough to express opinions that would get them stoned to death by the general public. And I can see why political incorrectness would be a useful quality in programming. Programs are very complex and, at least in the hands of good programmers, very fluid. In such situations it's helpful to have a habit of questioning assumptions." I definitely know a few coders I've worked with who I'd be comfortable raising my views on testing with. We might differ on the details (I quite like browser tests, don't find a lot of value in snapshot testing most of the time, we might unit test a different tiny subset of the app etc), but by and large we'd agree that most common testing is a crock. And coincidentally, they're all the devs that I think write fantastic code, and that I'd happily build a startup with. Anyway, that's my Thing I Believe About Software Engineering, with a bit more clarification than OP's ones.

astura 7y ago

>Being aligned with teammates on what you're building is more important than building the right thing. Goodness this is incredibly naive. It can only be true only if youre working without customers or stakeholders and who the hell works that way other than hobbyists and startups that are indiscriminately wasting other people's money? The vast majority of software I've written (I'm outside the valley) is written for actual paying customers, and it must be "the right thing," ie, exactly what they paid you to build. Beyond that, if you're, for example, writing an emulator and the emulator works different than the system it's emulating that's a failure no matter how "aligned" your team is. Nobody will buy it and nobody would even use if you gave it away.

C4stor 7y ago
Except that for a lot of developers, "the right thing" has nothing to do with what customers want, but rather with language used, libraries used, CI/CD setup, monitoring active... So many technical aspects that sometimes have nothing to do with the customer wants. And that's where being aligned makes sense.
sime2009 7y ago
> Goodness this is incredibly naive. Actually it demonstrates hard earned wisdom. A team which isn't aligned will only produce a mess regardless of whether their end goal was the right thing. An aligned team may miss the target but they will be in a position to correct themselves and pursue the target.

loxs 7y ago

> The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use. For me this is not true. The type system has a bigger impact on me. If I use a language with static types + IDE, I am quite productive even while chronically not getting enough sleep (currently looking after a newborn). Probably much more productive compared to writing in a dynamic language while getting enough sleep. And of course, that does not mean that sleep is not a huge factor. It most definitely is.

andruby 7y ago

> Being aligned with teammates on what you're building is more important than building the right thing. I would write this as: Building the right thing wrong is more important than building the wrong thing right. And I firmly believe that agreeing on _what_ you are builing is more important than _how_ you are building it. Mainly because it is easier to change the _how_ than it is to change the _what_.

karmakaze 7y ago
> Building the right thing wrong is more important than building the wrong thing right. I entirely agree with this, but don't think that's what the original point was getting at. > And I firmly believe that agreeing on _what_ you are building is more important than _how_ you are building it. Mainly because it is easier to change the _how_ than it is to change the _what_. This seems like it should be true. In practice, I've found that the _how_ is the part that gets embedded in the wet-ware of people/companies and is the hardest to change. Given an application written in a language with some framework, some datastore, deployed to some cloud, it's actually exceedingly easy to make another that follows that pattern and does a completely different business function. Much more challenging would be to change those parts of an application and keep it doing the same thing.
emmanueloga_ 7y ago
I read it as: "Build consensus before you start building any specific implementation". ... the idea being that it is better for a team to collaborate on a compromise solution than any given person pushing into their pet solution because they "know better".

EnderMB 7y ago

I clicked this expecting an overly opinionated list on how to do things the right way, but came away agreeing with nearly everything said. > Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. This is the one point I somewhat disagree with, and it leads to one of the things I believe about SE - it's all about perceived risk. Mission-critical systems work well because the risk is well-defined, and it's usually "people will die". In business, managers are happy to break rules when the perceived risk of it biting them in the ass is low. Small budget? Skip the tests, click around on deploy to see if it works, and ship it. Not enough time? Deliver a minimal product and build the rest later when we have the budget. There are two examples I often use for this - Panera Bread and Pipdig. The former leaked millions of customer records, ignored the press for a few days, and got off with zero consequences. Pipdig did even worse, they did backdoors and DDoS code to attack competitors in their WP themes/plugins, and when called out they lied, hid the evidence, and then went back to selling themes to unsuspecting bloggers with zero consequences. Both sides likely knew what they were doing was wrong, but the risk of getting caught was minimal, so why not break the rules? It probably saved them a ton of money in the long run. > Being aligned with teammates on what you're building is more important than building the right thing. I've no idea why so many of you are up in arms about this. It isn't about bowing to managers, or being a punching bag for others. It's about making concessions as a group to define what you need to build, and the best way of doing it. > Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. I'd stretch this to say that "on average". Some days I'll get 30 minutes of stuff done, some days I'll fly through work for a solid 8 hours. > Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill. This is so true it hurts. I'm currently working on a project in an agile structure, and it's going like many agile projects I've worked on in the past. Agile is used as a buzzword for "fuck planning, just write user stories and be done with it", all while team mates bitch and moan about spending too long in "planning" meetings. The second we took the time to actually have these meetings and plan out our backlog, we made key decisions and discoveries about how things work, what edge cases we need to think about, what doesn't work from a user perspective, etc. > How kind your teammates are has a larger impact on your effectiveness than the programming language you use. Over the years, I've always believed that empathy is the best skill you can have in software, and that is often paired together with kindness. An empathetic team is often a kind team, and when empathy is a core part of a team it highlights areas where certain stakeholders don't share that trait.

neilwilson 7y ago

I'm with Dijkstra "Our intellectual powers are rather geared to master static relations and ... our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible." As Systems Engineers we're probably better than 99% of the population at visualising the dynamics of the system, and even then we're still pretty bad at it. Humility in the face of this human limitation helps enormously I find.

prox 7y ago
I really like this quote, and humility in this case helps to more clearly view the problem (and hopefully solve it adequately)
crimsonalucard 7y ago
Humility should not preclude aggressive problem solving towards eliminating the gap. Be humble and be open to the possibility that this problem can be utterly destroyed. Have you heard of functional programming?
- skywhopper 7y ago
  The list of "things I believe" the OP cited mentions functional programming as a fundamental belief as well, because it "eliminates side effects" and doesn't "mutate state". And yet, these traits give us little or no help in troubleshooting problems in distributed computer systems, where side effects are inherent and state is in constant flux. Oh sure, to within the CAP theorem, you can keep your data store relatively consistent and immutable, but that's only helpful so long as all the rest of your infrastructure is infallible. Which it isn't.
  - smilliken 7y ago
    It's not about eliminating effects! It's about controlling them. A program that had no effect would be perfectly useless. In distributed systems, it's important to be very intentional about effects, instead of letting them creep into any part of your program.

bartread 7y ago

> Being aligned with teammates on what you're building is more important than building the right thing. I don't buy this. I'm not sure these two things should be placed in opposition (or at least tension) in this way. It makes for a nice soundbite but I don't think it withstands scrutiny. I've seen and worked in teams where alignment was great and we all worked really well together but, at the end of it all, nobody bought the damn product. I.e., we didn't build the right thing. Let's not kid ourselves: aligning and working well together to build the wrong thing is somewhat pointless (granted, you might learn some useful lessons along the way). Now, if you take that team and then assign them to build the right thing you have something really powerful.

mic47 7y ago
I read it more like this: If you are building right thing, but you are not aligned, then you will not build the right thing and you will fail. But if you are aligned, it's easier to steer the ship closer to the right thing.
- k__ 7y ago
  Sure. But I've seen too many dev departments building crap over and over again and feeling pretty good about themselves the whole time.
  - KnobbleMcKnees 7y ago
    > building crap over and over again and feeling pretty good about themselves I'm triggered
  - 6510 7y ago
    I wonder how few wrote something that in their own opinion wasn't crap and did something impressive.
    - k__ 7y ago
      Technically maybe.

EugeneOZ 7y ago

> The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry. It's not tests' fault that programmers are lazy and write tests not for every function, or write unit tests without integration tests or write vice versa. Whole article is just low-quality whining.

cixter 7y ago
woosh

lordnacho 7y ago

> Most measures of success are almost entirely uncorrelated with merit. This is life in general, no? Aside from maybe professional sports, where it's forced to be that way by design.

hliyan 7y ago

By some remarkable coincidence, @JanStette's version of this (1) and mine (2) have a lot of overlap. Maybe we should all write a version of this and see if common themes emerge. Jan and I clearly agree on coding, design and testing, for example. 1. https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d14e2b https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1... 2. http://zen.lk/2019/08/18/Things-I-believe/ http://zen.lk/2019/08/18/Things-I-believe/

classified 7y ago

Thank [insert relevant deity] I'm not a reasonable person, so I can afford to agree with all of the author's points. Especially the one about testing. And if that applies to you: Kick those amphetamines and get more sleep instead.

unnouinceput 7y ago

"<Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.>" You can say this about any tech field. Heck you can say this about social domains as well. And yet world marches over with progress being made. "<Being aligned with teammates on what you're building is more important than building the right thing.>" Because yeah, building the wrong thing was always good and had nothing to do with economic failures, right? Tell this also to NASA teams that build the moon race, is littered with teams doing different stuff and not being aligned. My favorite story for that is the one about how they made the suit. "<There are many fundamental discoveries in computer science that are yet to be found."> There are many fundamental discoveries in all fields that are yet to be found, CS is no more special then Psychology for example, it only pays better these days. "<Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours."> Peak productivity depends on each individual and within each individual there are seasons. I can be productive at nights or during day time, and when I am productive during certain hours for the life of me I would not be able to be productive on other hours. Procrastination is perception of individuals during their non-productive hours. "<Most measures of success are almost entirely uncorrelated with merit."> Finally, the single statement in this otherwise useless article that I can agree with. "<Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill."> That depends on what your education/how your parents raised you. As for how much value this has in current society, well just ask Trump (he's still a billionaire). Also, in that regard see previous point. "<The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry."> Actually the standards are quite high, you should've seen them 40 years ago when Ford preferred to allocate 200M USD for paying victims than rather improve its safety when building the chassis, because that would've eaten their profits ten fold. <"How kind your teammates are has a larger impact on your effectiveness than the programming language you use."> Become freelancer, be your own boss and you couldn't care less about teammates. One man show where you call all the shots is awesome. "<The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use."> This point goes hand in hand with above one about productivity, it all boils down to each individual.

karmakaze 7y ago

> Being aligned with teammates on what you're building is more important than building the right thing. It depends. If iterations are quick and the current direction is roughly on the path to finding the right thing yes, otherwise no unless you are choosing to redefine software engineering.

jmull 7y ago

> Most measures of success are almost entirely uncorrelated with merit. A more important and useful thing to understand is that merit is measured by rules that bubble out of social systems. A mistake you can make is to believe the the rules of merit that you believe are the same ones others believe, that the ones they state are the same ones they actually believe, that the rules don't depend on context, etc. It's hard for people to accept this because we're taught that merit is an inherent quality, we may internalize the rules of merit we learn, treat them as constants, and then build our self-images based on those rules. (I'm not suggesting to give up on the idea of merit altogether, but you'll do better to think of it as something you achieve for personal satisfaction and not necessarily expect external rewards.) BTW, the rules of success (beyond the most basic stuff) are also social constructs, but they are different than the rules of merit. It's a mistake to expect them to necessarily be harmonious or consistent.

crimsonalucard 7y ago
I don't agree with 'most.' Our schooling and educational systems are very merit based. One could say that in the work place, success is uncorrelated with merit.
- NohatCoder 7y ago
  School and workplace is just an example of two very different merit systems. One is not inherently more right than the other.
  - crimsonalucard 7y ago
    Never said one is more right. But merit in the workplace is not quantitatively measured in any form.
- oarabbus_ 7y ago
  >One could say that in the work place, success is uncorrelated with merit. Do you truly believe this? In my career experience, success is highly correlated with merit. Sure, I have seen plenty of incompetence at high positions, and I've seen brilliant people who received little success in their careers. But overall, I'd say the correlation is very high.

karmakaze 7y ago

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Pair programming can easily double that and the low productivity periods are not nearly as low.

bartread 7y ago
> Pair programming can easily double that and the low productivity periods are not nearly as low. Pfft. Prove it. People are very different and work best in different ways. I don't mind pair programming for specific reasons but as a the "normal" way of working? You can keep it. Pair programming performed relentlessly selects for certain personality types. I, for example, didn't get into programming because I wanted to sit around talking all day. Far from it. Programming is a creative endeavour, kind of like songwriting. Some people are great solo songwriters, some people work well together, people often struggle to cross that divide and, even if they collaborate well, may struggle to collaborate well with everyone. I can work effectively in a team but under most circumstances I cannot program at my best with somebody hovering around or buzzing in my ear all time. And, believe me, I am by no means unusual in that regard. Mandatory pair programming is one of those things that, I think, seems like a good idea to third rate management who don't want to take the time to understand how the people on their teams can work together most effectively.
- karmakaze 7y ago
  All good points and I was of the same opinion before I underwent almost 2 years of mostly pairing. My takeaways: People are different. The core bunch came from Pivotal which performed pair-programming interviews so were self selected. That accounted for about half the engineering staff so the other half didn't undergo this process. I myself have always been a solo developer so pairing was very unnatural at first and I didn't pair well with everyone. We rotated pairs every week (sometimes two) so that wasn't a big problem. There are times when solitary deep thought is useful and breaks for that activity could be taken at will while the other pair works on maintenance tasks etc. Most of the time the work isn't of this type and more often less complex requiring light whiteboarding or on-screen prototyping which both work well when pairing. The style of code that comes out of pairing tends to be more plain than when working solo. There is incremental progress in both implementations and design refinements when pairing. When working solo there tends to be grander designs with a moment where it all comes together or not. I enjoy the latter but find the former higher by average throughput. Pairing tends to eliminate more of the 'might need soon' or 'will need in the future anyway' implementations. After pairing with someone a few times, verbal communication becomes very terse and fluid. An unexpected benefit was the ability to immediately resume context after interruptions or breaks. The biggest advantage of pair-programming that doesn't get mentioned much is the organic spread of good practices and conventions. With approximately 20 devs it's not really worth writing and maintaining standards documentation and conventions for handing new cases that keep appearing. With rotating pairs this discovery of what works well and normalization upon it is natural. Minor tips and tricks aside from the source code can also be invaluable power-ups when learned by others. Pair programming isn't about maximizing 'your own productivity' it's about maximizing the productivity, quality, and consistency across all dev teams. Within that period we also tried full-stack dev pairing. This was much more challenging and didn't work nearly as well. We didn't stick with it long enough to know if it could become more beneficial because basically people self-selected into front or back-end development and liked it that way. These are my findings from being both a solo and pair-programming developer. If you're curious and have an opportunity I highly recommend trying to stick with it for a while and see what your findings are.

AJRF 7y ago

> "Read the classics. So many “new” ideas in software development have actually been around for decades." From the original post that inspired this post: https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d14e2b https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1... What would HN say are the "classics"?

dschadd 7y ago
Pragmatic Programmer and Code Complete are usually mentioned as classic programmer text books. I own both and have probably read 10 pages between the 2 books.
- boring_twenties 7y ago
  I haven't read Code Complete but I did flip it open to a random page around halfway through the book, and was treated to a page-long explanation about the fact that conditions in loops aren't constantly being evaluated, but only once at the top of each loop. I think it's reasonable to simply assume the entire book is bullshit after that.
stronglikedan 7y ago
I don't know if it's a "classic", but I recently picked up a copy of Wicked Problems, Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms [0] after reading through another HN thread on good software dev books. I haven't cracked it open yet though. [0] https://books.google.com/books/about/Wicked_Problems_Righteous_Solutions.html https://books.google.com/books/about/Wicked_Problems_Righteo...
- varrock 7y ago
  Can you link the HN thread about good software development books?

DBYCZ 7y ago

His last point is my favorite, I feel useless at work if I don't get decent sleep. He should append working out and going for walks to that as well.

antirez 7y ago

> There are many fundamental discoveries in computer science that are yet to be found. That's a strange claim. It could be, but there are large evidences that we discover most of the fundamental things immediately up to the 80s, and then the other improvements are kinda really incremental, a program from 1970 is not alien today. Technology of computing progressed a lot more than CS itself, a computer of 1970 kinda is alien, and a toy.

wry_discontent 7y ago
Your description of how things are is exactly how Thomas Kuhn describes the process of "Normal Science" in The Structure of Scientific Revolutions. Cracks in our understanding grow, and patchwork theories are put around those contradictions, but eventually the dam breaks and a scientific revolution reshapes the way we think about a subject.
jdance 7y ago
I don't think we will sit at our computers writing code in the same way a hundred years from now. It just feels very inefficient to me, it's a good abstraction for now but better will come, new paradigms that probably look radically different. I personally would find the opposite claim rather strange :)

pmiller2 7y ago

Here is my (unpopular? original?) opinion about software engineering: software engineering is more like writing a novel than building a bridge. Bridges are fairly well understood, and the parameters necessary to build them successfully can be approximated very closely once it’s decided what materials to use. Software will surprise you, in the sense of “no battle plan survives contact with the enemy.” You will have bad data in prod. Users will do unexpected things. You won’t always be able to reach S3. And, this is all true even assuming the software is written perfectly to spec. Knuth has famously said he thinks reusable code isn’t all it’s cracked up to be. It’s re-editable code that we ought to all be striving for. There are two aspects to this. First, how often do you get to write entirely new code inside a mature software project? Not often, I would wager, so why not make the job as easy on future you as possible? Second, re-editable code needs to be understood before it can be edited to extend it. This means we need to write code for humans to read, and computers, only incidentally, to execute (I think EWD might have said something to that effect).

kikimora 7y ago
> You will have bad data in prod. Users will do unexpected things. You won’t always be able to reach S3. And, this is all true even assuming the software is written perfectly to spec. Surprisingly this nonsense happens in a discrete setting where we can (in theory, of course) enumerate all possible inputs. Again surprisingly we cannot find effective way to automagically partition input space into equivalence classes to assist us in testing. Novel works in conjunction with our brains and it is not surprising that there are no definitive rules or “good novel equation”. But programs implement defined algorithms and super predictable. Yet creating them feels like writing a novel. I agree with your statement but at the same time it feels wrong that we find ourselves in such position.

l0b0 7y ago

> Being aligned with teammates on what you're building is more important than building the right thing. It's important to define the terms here. Does "important" mean important to you or the company? I could understand the former, but how are you ever going to build the "right thing" if you can't agree as a team what you're building?