TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Things I Believe About Software Engineering

420 pointsby turingbookover 5 years ago

28 comments

neilwilsonover 5 years ago
I&#x27;m with Dijkstra<p>&quot;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.&quot;<p>As Systems Engineers we&#x27;re probably better than 99% of the population at visualising the dynamics of the system, and even then we&#x27;re still pretty bad at it.<p>Humility in the face of this human limitation helps enormously I find.
评论 #22223419 未加载
评论 #22228594 未加载
评论 #22225773 未加载
jmullover 5 years ago
&gt; Most measures of success are almost entirely uncorrelated with merit.<p>A more important and useful thing to understand is that merit is measured by rules that bubble out of social systems.<p>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&#x27;t depend on context, etc.<p>It&#x27;s hard for people to accept this because we&#x27;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.<p>(I&#x27;m not suggesting to give up on the idea of merit altogether, but you&#x27;ll do better to think of it as something you achieve for personal satisfaction and not necessarily expect external rewards.)<p>BTW, the rules of success (beyond the most basic stuff) are also social constructs, but they are different than the rules of merit. It&#x27;s a mistake to expect them to necessarily be harmonious or consistent.
评论 #22225839 未加载
einpoklumover 5 years ago
&gt; Being aligned with teammates on what you&#x27;re building is more important than building the right thing.<p>So, let&#x27;s cave in to peer pressure or management dictates and continue down the wrong path (technically&#x2F;socially)?<p>Strongly disagree with that.<p>&gt; Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.<p>Here I mostly agree. The thing is, that you don&#x27;t know in advance when these hours are going to happen. Also, sometimes it&#x27;s 2, sometimes 0 and sometimes 8.<p>&gt; The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use.<p>(Yawn) Indeed...
评论 #22222822 未加载
评论 #22224394 未加载
评论 #22222830 未加载
评论 #22225924 未加载
pmiller2over 5 years 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.”<p>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.<p>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).
评论 #22230857 未加载
jwrover 5 years ago
Couldn&#x27;t agree more with every point listed. These are fantastic points.<p>I do not know the author, but reading these points makes me suspect he&#x2F;she is an experienced software engineer that has been doing this for many years now.<p>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.
评论 #22223459 未加载
评论 #22223062 未加载
评论 #22225594 未加载
评论 #22223161 未加载
评论 #22224547 未加载
评论 #22227337 未加载
评论 #22224779 未加载
andrubyover 5 years ago
&gt; Being aligned with teammates on what you&#x27;re building is more important than building the right thing.<p>I would write this as:<p>Building the right thing wrong is more important than building the wrong thing right.<p>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_.
评论 #22230651 未加载
评论 #22231713 未加载
mtrycz2over 5 years ago
&gt; Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.<p>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.<p>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 &quot;software engineering&quot; is all about craftsmanship, and just a sprinkle of actual engineering to make ourselves feel good.
评论 #22223437 未加载
评论 #22223263 未加载
评论 #22222967 未加载
评论 #22223212 未加载
评论 #22224054 未加载
评论 #22225964 未加载
评论 #22224954 未加载
评论 #22222969 未加载
评论 #22223093 未加载
评论 #22223128 未加载
评论 #22223165 未加载
评论 #22227307 未加载
评论 #22223006 未加载
评论 #22223034 未加载
评论 #22222950 未加载
评论 #22223100 未加载
评论 #22224463 未加载
评论 #22223159 未加载
评论 #22222973 未加载
评论 #22225184 未加载
评论 #22222953 未加载
评论 #22223137 未加载
评论 #22224153 未加载
评论 #22223013 未加载
评论 #22222951 未加载
评论 #22224820 未加载
评论 #22223246 未加载
asturaover 5 years ago
&gt;Being aligned with teammates on what you&#x27;re building is more important than building the right thing.<p>Goodness this is incredibly naive.<p>It can only be true <i>only</i> 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&#x27;s money? The vast majority of software I&#x27;ve written (I&#x27;m outside the valley) is written for actual paying customers, and it must be &quot;the right thing,&quot; ie, <i>exactly</i> what they paid you to build.<p>Beyond that, if you&#x27;re, for example, writing an emulator and the emulator works different than the system it&#x27;s emulating that&#x27;s a <i>failure</i> no matter how &quot;aligned&quot; your team is. Nobody will buy it and nobody would even use if you gave it away.
评论 #22223717 未加载
评论 #22223226 未加载
bartreadover 5 years ago
&gt; Being aligned with teammates on what you&#x27;re building is more important than building the right thing.<p>I don&#x27;t buy this. I&#x27;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&#x27;t think it withstands scrutiny.<p>I&#x27;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&#x27;t build the right thing. Let&#x27;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.
评论 #22223451 未加载
评论 #22223309 未加载
评论 #22223477 未加载
评论 #22223522 未加载
评论 #22223891 未加载
评论 #22223486 未加载
评论 #22223587 未加载
crypticaover 5 years 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.<p>Knowledge can be divisive because it&#x27;s often communicated through rigid (black or white) statements and founded on outlier experiences but wisdom is generally not divisive; wisdom usually doesn&#x27;t get people as excited but it&#x27;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.<p>I tend to think that upvote&#x2F;downvote mechanisms (Like on Reddit and HN) are somewhat of a threat to the sharing of wisdom because wise ideas don&#x27;t create that dopamine rush which clever ideas do (they don&#x27;t trigger the strong feelings required for upvote&#x2F;downvote). Wisdom is rarely surprising or controversial.<p>Even discussing the idea of wisdom seems to be taboo. As if it&#x27;s some kind of outdated concept; but the irony is that it&#x27;s more relevant now than ever.
AJRFover 5 years ago
&gt; &quot;Read the classics. So many “new” ideas in software development have actually been around for decades.&quot;<p>From the original post that inspired this post: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;stettix&#x2F;5bb2d99e50fdbbd15dd9622837d14e2b" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;stettix&#x2F;5bb2d99e50fdbbd15dd9622837d1...</a><p>What would HN say are the &quot;classics&quot;?
评论 #22224941 未加载
评论 #22224870 未加载
hliyanover 5 years ago
By some remarkable coincidence, @JanStette&#x27;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.<p>Jan and I clearly agree on coding, design and testing, for example.<p>1. <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;stettix&#x2F;5bb2d99e50fdbbd15dd9622837d14e2b" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;stettix&#x2F;5bb2d99e50fdbbd15dd9622837d1...</a><p>2. <a href="http:&#x2F;&#x2F;zen.lk&#x2F;2019&#x2F;08&#x2F;18&#x2F;Things-I-believe&#x2F;" rel="nofollow">http:&#x2F;&#x2F;zen.lk&#x2F;2019&#x2F;08&#x2F;18&#x2F;Things-I-believe&#x2F;</a>
tr1coderover 5 years ago
&gt; Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.<p>Is it possible to improve this by training? For example if I&#x27;m productive 2 hours and force myself to be productive 10-30 more minutes each day for a number of days and when I&#x27;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?
评论 #22223117 未加载
评论 #22223007 未加载
评论 #22222983 未加载
评论 #22223597 未加载
评论 #22222975 未加载
评论 #22223043 未加载
评论 #22222898 未加载
评论 #22223472 未加载
评论 #22223619 未加载
DBYCZover 5 years ago
His last point is my favorite, I feel useless at work if I don&#x27;t get decent sleep. He should append working out and going for walks to that as well.
mslaover 5 years ago
&gt; Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.<p>I think it&#x27;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.<p>This has implications for job automation.<p>&gt; Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill.<p>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.<p>This has implications for software testing. It has implications for all kinds of testing.
评论 #22222966 未加载
karmakazeover 5 years ago
&gt; Being aligned with teammates on what you&#x27;re building is more important than building the right thing.<p>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.
loxsover 5 years ago
&gt; The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use.<p>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.<p>And of course, that does not mean that sleep is not a huge factor. It most definitely is.
lordnachoover 5 years ago
&gt; Most measures of success are almost entirely uncorrelated with merit.<p>This is life in general, no? Aside from maybe professional sports, where it&#x27;s forced to be that way by design.
antirezover 5 years ago
&gt; There are many fundamental discoveries in computer science that are yet to be found.<p>That&#x27;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.
评论 #22225459 未加载
评论 #22228512 未加载
l0b0over 5 years ago
&gt; Being aligned with teammates on what you&#x27;re building is more important than building the right thing.<p>It&#x27;s important to define the terms here. Does &quot;important&quot; mean important to <i>you</i> or the company? I could understand the former, but how are you ever going to build the &quot;right thing&quot; if you can&#x27;t agree as a team what you&#x27;re building?
BigJonoover 5 years ago
&gt; The fact that current testing practices are considered &quot;effective&quot; is an indictment of the incredibly low standards of the software industry.<p>This is an interesting one. I first took it to mean &#x27;current testing practices are inadequate&#x27;, which isn&#x27;t an extreme opinion, and one I bet 99% of HN agrees with. It&#x27;s &#x27;common wisdom&#x27; that teams should be doing more testing, TDD, etc.<p>But now that I read it again, it&#x27;s specifically saying that current testing practices are &#x27;ineffective&#x27;, not &#x27;inadequate&#x27;, which would indicate we should be doing less or even none of it. &#x27;ineffective&#x27; to me means worse than nothing, since testing, like anything, has a cost. (time wasted, more code to maintain, lower morale etc)<p>I&#x27;m not sure which the author meant. But I do think the latter is a hot take, and I get the feeling I&#x27;m in the minority in agreeing with it.<p>I&#x27;m reminded of this PG quote (obviously written a while ago):<p>&quot;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.&quot;<p>If I think about what I&#x27;ve written unit tests for at home, that&#x27;d be a bunch of maths-y stuff that I was having trouble debugging, and a few functions here and there that I consider &#x27;tricky&#x27; and want a bit of extra peace of mind for.<p>When I&#x27;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&#x27;t quantify why. I just <i>know</i> intrinsically that they&#x27;re useless and it&#x27;s a waste of time. I just <i>know</i> that 95% of my code works and I <i>know</i> what the 5% I&#x27;m unsure about is and what manual testing or browser testing I need to do to clarify it.<p>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&#x27;m happy to smile and nod for the right salary).<p>Then there&#x27;s this, from the same essay:<p>&quot;One difference I&#x27;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&#x27;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&#x27;s helpful to have a habit of questioning assumptions.&quot;<p>I definitely know a few coders I&#x27;ve worked with who I&#x27;d be comfortable raising my views on testing with. We might differ on the details (I quite like browser tests, don&#x27;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&#x27;d agree that most common testing is a crock. And coincidentally, they&#x27;re all the devs that I think write fantastic code, and that I&#x27;d happily build a startup with.<p>Anyway, that&#x27;s my Thing I Believe About Software Engineering, with a bit more clarification than OP&#x27;s ones.
评论 #22223131 未加载
评论 #22225433 未加载
评论 #22224560 未加载
评论 #22225179 未加载
评论 #22223270 未加载
jingw222over 5 years 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&#x27;m with OP.
karmakazeover 5 years ago
&gt; Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.<p>Pair programming can easily double that and the low productivity periods are not nearly as low.
评论 #22226161 未加载
karmakazeover 5 years ago
&gt; There are many fundamental discoveries in computer science that are yet to be found.<p>Purely in the realm of computer science and has little the no bearing on a software engineering context.
评论 #22225228 未加载
EnderMBover 5 years 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.<p>&gt; Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.<p>This is the one point I somewhat disagree with, and it leads to one of the things I believe about SE - it&#x27;s all about perceived risk. Mission-critical systems work well because the risk is well-defined, and it&#x27;s usually &quot;people will die&quot;. 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.<p>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&#x2F;plugins, and when called out they lied, hid the evidence, and then went back to selling themes to unsuspecting bloggers with zero consequences.<p>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.<p>&gt; Being aligned with teammates on what you&#x27;re building is more important than building the right thing.<p>I&#x27;ve no idea why so many of you are up in arms about this. It isn&#x27;t about bowing to managers, or being a punching bag for others. It&#x27;s about making concessions as a group to define what you need to build, and the best way of doing it.<p>&gt; Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.<p>I&#x27;d stretch this to say that &quot;on average&quot;. Some days I&#x27;ll get 30 minutes of stuff done, some days I&#x27;ll fly through work for a solid 8 hours.<p>&gt; Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill.<p>This is so true it hurts. I&#x27;m currently working on a project in an agile structure, and it&#x27;s going like many agile projects I&#x27;ve worked on in the past. Agile is used as a buzzword for &quot;fuck planning, just write user stories and be done with it&quot;, all while team mates bitch and moan about spending too long in &quot;planning&quot; 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&#x27;t work from a user perspective, etc.<p>&gt; How kind your teammates are has a larger impact on your effectiveness than the programming language you use.<p>Over the years, I&#x27;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&#x27;t share that trait.
评论 #22223865 未加载
classifiedover 5 years ago
Thank [insert relevant deity] I&#x27;m not a reasonable person, so I can afford to agree with all of the author&#x27;s points. Especially the one about testing.<p>And if that applies to you: Kick those amphetamines and get more sleep instead.
unnouinceputover 5 years ago
&quot;&lt;Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.&gt;&quot;<p>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.<p>&quot;&lt;Being aligned with teammates on what you&#x27;re building is more important than building the right thing.&gt;&quot;<p>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.<p>&quot;&lt;There are many fundamental discoveries in computer science that are yet to be found.&quot;&gt;<p>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.<p>&quot;&lt;Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.&quot;&gt;<p>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.<p>&quot;&lt;Most measures of success are almost entirely uncorrelated with merit.&quot;&gt;<p>Finally, the single statement in this otherwise useless article that I can agree with.<p>&quot;&lt;Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill.&quot;&gt;<p>That depends on what your education&#x2F;how your parents raised you. As for how much value this has in current society, well just ask Trump (he&#x27;s still a billionaire). Also, in that regard see previous point.<p>&quot;&lt;The fact that current testing practices are considered &quot;effective&quot; is an indictment of the incredibly low standards of the software industry.&quot;&gt;<p>Actually the standards are quite high, you should&#x27;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&#x27;ve eaten their profits ten fold.<p>&lt;&quot;How kind your teammates are has a larger impact on your effectiveness than the programming language you use.&quot;&gt;<p>Become freelancer, be your own boss and you couldn&#x27;t care less about teammates. One man show where you call all the shots is awesome.<p>&quot;&lt;The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use.&quot;&gt;<p>This point goes hand in hand with above one about productivity, it all boils down to each individual.
EugeneOZover 5 years ago
&gt; <i>The fact that current testing practices are considered &quot;effective&quot; is an indictment of the incredibly low standards of the software industry.</i><p>It&#x27;s not tests&#x27; fault that programmers are lazy and write tests not for every function, or write unit tests without integration tests or write vice versa.<p>Whole article is just low-quality whining.
评论 #22223642 未加载