33 ms·

Things I’ve learned in my 20 years as a software engineer

• api 5y ago
  I’ve been into it about 25 years. Here’s a few of mine. 1. This industry is very faddish, and many fads are designed to make money for the people driving them or lock you into someone’s ecosystem. Avoiding those is a superpower. A ton of today’s cloud native trends fit into this category. They are gateways to a paradigm where you buy a lot of things as a service at a massive markup that are relatively easy to do locally or obtain at much lower rates. 2. Simplicity is harder than complexity. Managing complexity is merely clever while eliminating it is intelligent. Eliminating it without sacrificing coverage of the problem domain is genius. There is some very interesting academic literature on the idea that intelligence is or at least heavily involves data compression (and that this is what "learning" is), so this has some basis beyond the field. 3. Unfortunately re: #2 more complex less elegant solutions often win. Many argue that this is because they capture more of the problem domain, but I often disagree. I think it's a mixture of sophomore developers being impressed by complexity (having not yet learned #2) and the fact that complexity creates industries where money can be made on adjacent software, services, and consulting. As a result of the latter complex clunky solutions can be better at building an ecosystem full of self-interested evangelists. Recent example: Kubernetes vs. the Hashicorp stack. 4. If you make something work, you are only maybe a quarter of the way to making it a product. UI/UX is the rest of the journey. UI/UX tends to not be fun, so people have to be paid to do it. This is why open source and open systems almost always fail to achieve wide adoption beyond developers and IT people. They have no economic model, so they can't hire people to make the product usable for people other than nerds. 5. Infosec people are usually afraid of the wrong things. Most breaches involve social engineering or a passive mode of entry. Infosec people like to obsess about things that are sexy like cryptography but will happily type "npm install" as root on production and pay far too little attention to security against social engineering vectors. 6. There are 10X (ish) developers just like there are 10X athletes, 10X mathematicians, 10X writers, 10X salespeople, 10X musicians, and so on. The reason many people don't believe in 10X developers is that it's so hard to objectively measure developer productivity, especially at scale.
• progx 5y ago
  Expect always the worst case. Don't assume anything. If it is not the worst case, be happy, it saves you work. If it is the worst case, be happy, you expected it.
• debarshri 5y ago
  One of the things I have noticed lately is that people who change jobs often have completely different perception of the industry as compared to people who don't change that often. Both of the strategies have pros and cons. For instance people who change jobs quite often don't seem to care alot about the business per say they seem to emphasis on the technology more as compared to people who stick to one org. However, people who have changed job quite often, seem to have seen broad variety to problem sets and always bring fresh new pair of eyes to existing business. People who stick to the same org, do tend to become very conservative but it often good for the business as people not quitting brings lot of stability. Again, it really depends on situation, person to person. In general this is my observation.
  • ozim 5y ago
    If you are good in tech that is transferrable skill. Being good at what your company does is often not that useful anywhere else and usually you get non-compete so you cannot really use it. If someone is a dev it is better to switch jobs and sharpen your "software stack" skills than waste time on learning whatever business needs. Of course there is some level that one has to understand the business they make code for - but don't overdo it.
    • debarshri 5y ago
      You can always argue that every 5 years there is shift, sharpening your software stack might be a continuous process as compared to being a domain expert
  • hinkley 5y ago
    If you stay put, you start to believe your own PR. IF you move around you see that most of the things people fixate in aren’t that important or critical, and meanwhile some of the things they refuse to look at are and probably should be fixated on. The apparent differences in priority aren’t necessarily bad or even indicate less concern. They just aren’t as interested in the pet concerns of some verticals that are not universal. If you’ve been at the same place 5-10 years you have seen only a few rodeos, as it were. Their speculations on how things will play out are based largely on hope, not experience.
• StatsAreFun 5y ago
  5. Software is a means to an end Yes, yes and yes. Many times we lose sight of the fact our job is to support the business (money-making) functions of the company. The software itself isn't the end-all-be-all point of what the organization does unless you write open source software all day long and survive off donations. My gut tells me that most departments are like this and sees themselves as the core of the company but I think software engineers think of themselves more highly than most (and more highly than they should). A bit of humility would really help - myself included more than most probably. I agree with a lot of what he says... A few points are a little off IMHO but I've only been doing this for a few more years than this gentleman. Perhaps I'll feel differently in a few more. :)
• hhyndman 5y ago
  An excellent article. Thank you for your insights. I used to run a software engineering practice and I must admit that almost all of your points resonated with me. I'd like to add that one should catch oneself when falling into the "Perfect is the enemy of good" trap. As engineers, we would like things to be perfect, but sometimes at the peril of late delivery, little feedback, and development of features not required.
• papito 5y ago
  # 20 - Always strive to build a smaller system, is probably the most important one. The new generation of engineers have yet to learn (again) that complexity kills. The amount of resources spent maintaining unnecessary complexity is staggering. Your small thing does not have to be a distributed system.
• sas224dbm 5y ago
  Learned: software that you write will ALWAYS be for other people to pick-up, and that is hard. Keeping things simple is a tool to that end.
• johnmato 5y ago
  This is an interesting perspective. As a developer, I already realized that there's too much to learn as our technology is progressing rapidly.
• nicholast 5y ago
  If you try to wait for the money making opportunity in order to build something it may never come. Just start building. Keep building. There are more ideas at the end of a long path than there are at the start. If you don’t keep building they will remain unseen.
• Buttons840 5y ago
  > 4. The best code is no code, or code you don’t have to maintain > 17. Keep your processes as lean as possible > 20. Always strive to build a smaller system He stops just short of saying it, but IMO a program with fewer lines of code is almost always better. You can write your Java in Python and have it be 1/5th the lines. You can drop the classes and use functions and save some lines. Exceptions to this rule only happen because lines of code isn't an infallible measure of "size" or complexity. > Project size is easily the most significant determinant of effort, cost and schedule https://blog.codinghorror.com/diseconomies-of-scale-and-lines-of-code/ https://blog.codinghorror.com/diseconomies-of-scale-and-line... This comes to mind after having written some short pieces of code which get "improved" by others. But all they did was move things into different files and turn some functions into classes. As though what makes good code is trivially wrapping everything in a class. I can't understand it.
  • Zababa 5y ago
    I think that's because non-generated lines of code are a form of "incompressible human work". Sure, one person can write twice as much lines as another. Even 10! But when you have a codebase of 10 millions lines of code, this is going to take a certain amount of man-years, and there is no way to reduce that. This is in stark contrast to the programs we write, that can replace large quantities of human work easily. Some other ways of looking at this: compilers are an impressive force multiplier. When you compare the size of the source and the size of the executable, it's easy to see how much work you avoid. Compilers allow one single person to create way bigger programs. That would also explain why some people are so insistent on Lisp: macros are compilers. If you can write your own compiler, you can increase even more your own productivity. This raises the question of why not everyone uses Lisp. The answer is collaboration. Collaboration happens when people share a mental model of things. The bigger the language, the harder it is to find lots of people that share that entire mental model. This may be why you often hear programmers with a lot of experience that prefer "small and simple" things, like C or Go. It makes collaboration easier. Dynamic vs static typing might be the same. It's about "how much context you need in your head at all time". If you have a lot of context in your head, it's easy to think about things succinctly. But when people don't have the same context as you or you lose yours, understanding their short and full of context code might be very hard. Spaghetti programs are that, a mix of context. You can't take one spaghetti out. You have the same exact problem in parsing, context-free vs context-sensitive grammar. I don't know if and how the context-free vs context-sensitive ideas translate in terms of people. If anyone really likes using Lisp or Go or Haskell, I would be interested in your opinion about my "theory", and if you think that preference for context-free or context-sensitive applies to other parts of your life or personality.
• lincpa 5y ago
  You might like a programming methodology based on elementary school mathematical models (take Clojure as example)----The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model. Based on the simplest and most vivid mathematical model is its biggest advantage. Its mathematical prototype is the "water in/out of a pool" problem in elementary school mathematics. When we increase the number of pools and water pipes, the combination of different types of liquids, the time and speed of input and output, and other factors in this mathematical problem. It forms a warehouse/workshop model in the form of a dynamic tree Gantt chart. It should be the IT architecture with the simplest and most vivid mathematical prototype. It is an epoch-making theoretical achievement in the IT field, it surpasses the "von Neumann architecture", unifies the IT software and hardware theory, and raises it from the manual workshop production theory level to the modern manufacturing industry production theory Level. Although the Apple M1 chip has not yet fully realized its theory, Apple M1 chip has become the fastest chip in the world. It has a wide range of applications, from SOC to supercomputer, from software to hardware, from stand-alone to network, from application layer to system layer, from single thread to distributed, from general programming to explainable AI, from manufacturing industry to IT industry. The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model: https://github.com/linpengcheng/PurefunctionPipelineDataflow https://github.com/linpengcheng/PurefunctionPipelineDataflow
• sporedro 5y ago
  I feel like once you’ve worked on a few projects the desire to “reinvent” the wheel is quickly destroyed. The main thing they never teach in school and you really can’t understand until your doing it is maintenance. Projects are like a balancing act where you need to weigh the pros and cons of every choice and choose the best one. The hard part is being able to do that and do it in a reasonable amount of time.
  • jb3689 5y ago
    The difference between a senior engineer and a junior engineer to me is that a senior engineer knows how to evolve a system into the system that they want/need it to be. They don't just say "well, looks like we have to throw the whole thing out the window and use this other new shiny/rebuild it from scratch". The desire to reinvent is important to keep throughout your years as long as it is rooted in reason and in the best intentions of the team and company. Riffing on that, more senior engineers better know how to evolve those systems (whether that is working with larger systems or working on people problems or working to support large customers, etc)
    • mgkimsal 5y ago
      Whenever I've "started over", I've sometimes longed for going back to pre-existing stuff and evolving it. Sometimes, but not always. Whenever I've 'evolved' existing systems, I've almost always wish we'd started over (or some variation thereof). Recent-ish project: holding on to multi-year old legacy data that was simply bad/broken (but was assumed to be good because it was barely used/examined), then requiring every single new feature to work flawlessly with broken data, ensuring that legacy customers 'never' hit an error (when 95% of them have not logged in in years). That's a candidate for 'rewrite from ground up' - you can keep an old system going in maintenance mode, build the archetypal "version 2", then decide if/when/how to migrate old data over... Knowing that you can 'evolve' a system towards improvements and knowing when you should do that is another sign. Something may be technically possible, but the time/effort/cost can outweigh whatever benefits there may be.
• the_only_law 5y ago
  > “How can you not know what BGP is?” “You’ve never heard of Rust?” Most of us have heard these kinds of statements, probably too often. My problem is I’ve heard of it, probably even know a bit about it but never used or worked with it. Meanwhile it seems like everyone around me is both an insane domain expert in their own thing while also a pretty damn good generalist having worked across everything.
• JackFr 5y ago
  30 years of experience, 2 more: * You don't know what the hard part was until the software is in production. * If you know the right way to do it, do it the right way.
• SergeAx 5y ago
  > We should be far more focused on avoiding 0.1x programmers than finding 10x programmers Exactly my words two weeks ago: https://news.ycombinator.com/item?id=28640661 https://news.ycombinator.com/item?id=28640661 We as an industry really should put a lot of effort into helping 0.1x coders improve their skills to 1x level.
• ozim 5y ago
  I think I agree with every point on that post. Only thing that I would add to the context: If someone is a junior developer and has position where he has to "just write code" don't worry much about that advice. Yes you should understand what this advice is and look for ways to grow into that mindset but as junior dev such person still has privilege to fully focus on coding stuff as quickly as possible to learn have their movements worked out. Then as such junior gets to 2 or more years of experience this advice should sink in and such person should start working as those points guide. After 2 years of being code monkey and having the feel for the code one can start looking at bigger picture.
• ravenstine 5y ago
  I have some comments as a software engineer of 8+ years of professional experience. > 1. I still don’t know very much Yep. > 2. The hardest part of software is building the right thing That's definitely hard but I'd say it's the people that are the hardest part. > 3. The best software engineers think like designers I'm not sure I entirely agree. It's also in total conflict with the growth economy the employs many of us; properly designing stuff takes time. No matter what, I always end up in a situation where "they want this as soon as possible". Being able to take the time to actually design something seems more like the exception than the norm. The only way around it is experience so that something resembling good design can occur by knee-jerk. > 4. The best code is no code, or code you don’t have to maintain > 5. Software is a means to an end > 6. Sometimes you have to stop sharpening the saw, and just start cutting shit Yes. > 7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system Honestly, I don't that any of us have a good grasp of the universe of possibilities. A "good" system is highly subjective. Bad code is at least somewhat measurable if it doesn't work, isn't efficient, or takes a long time for engineers to understand. There may be no such thing as good code. There's working code and there's code that fails to do its job. > 8. Every system eventually sucks, get over it I'd put an asterisk in front of "every". Many "good" systems turn out to suck not only because people ruin them but because engineers learn, grown, and change. While I tend to hate codebases more over time, there are some that I come back to years later and am still impressed by. > 9. Nobody asks “why” enough Yes. This has to be part of company culture, however. Many get defensive when subordinates question even the simplest of things, no matter how much they encourage that you "ask questions". > 10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers Maybe, but I've met more 10x developers than I have 0.1x. And I've met exactly one 10x developer. There was one guy who got canned at the first company that I worked for, and my bosses justified it because they thought he "wasn't doing anything". In actuality, he was directed poorly. Some people can just ignore bullshit management but others need seniors who can provide direction and some level of mentorship. That doesn't mean they are 0.1x developers. It may mean that team leaders haven't managed to find that developer's particular strength. The closest I've found to 0.1x developers were some dudebros I met during my education, but every one of them flunked out. > 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be I've always had opinions so I'm not sure I relate to this as a senior engineer. I have more opinions, and sometimes more nuanced ones, but in many ways I feel similar to how I did as a junior engineer. I'm frequently astounded by how much more I need to learn. I guess the major difference I see is in the kind of opinions. Many juniors have opinions, but they are largely additive. Senior engineers who have been in the battle field long enough have opinions but they're more subtractive, or saying "you know, we don't need to add more steps to our toolchain, and maybe we don't need another framework". > 12. People don’t really want innovation Innovation rocks the boat for businesses beyond a certain "escape velocity" and what many consider "innovative" is actually confusing since innovation by definition is non-standard. > 13. Your data is the most important part of your system > 14. Look for technological sharks > 15. Don’t mistake humility for ignorance Yes. > 16. Software engineers should write regularly Meh. > 17. Keep your processes as lean as possible If I had things my way, I'd get rid of "standups" and "retros", uninstall unadulterated bullshit like Pivotal Tracker in favor of something much simpler like Trello or even a Google spreadsheet, eliminate estimations, and only have meetings that are goal oriented. > 18. Software engineers, like all humans, need to feel ownership > 19. Interviews are almost worthless for telling how good of a team member someone will be > 20. Always strive to build a smaller system Yes.
• agentultra 5y ago
  Avoid the word 'just' and be suspicious of those that use it: It's just a new model and a few pages, how hard could it be? It should take just a couple of weeks. When people use this word they are being overly optimistic about something they're not sure of. It's harder than you think: The name of the game is to avoid fooling yourself and you're the easiest person to fool (that's from Feynman). If the problem seems hard it probably is harder than you think. Be ruthless and don't settle for unsatisfactory, hand-waving solutions to these problems. Most people can't detect deadlocks or temporal properties of concurrent programs in their heads.
• Arjuna 5y ago
  ”The 10x programmer is a silly myth.” Incredibly high performers exist, but are rare. For example, the following quote is from a talk given by Gabe Newell. (Unfortunately, I do not have the URL to the source video for this quote.) “At IBM in the 1980s, typical productivity would be 1,000 debugged, shipped lines of code per year. That was the metric that they used for their median employee. Where as, when we were shipping Half Life 1, one employee, Yahn Bernier, was shipping 4,000 lines of code per day.”
  • hereforphone 5y ago
    HalfLife 1 wasn't shipped in the 80s though. Maybe HL3 will be shipped in the (20)80s.
  • jeremyjh 5y ago
    If you measure lines of code you will indeed find people who produce a lot of it. Is that a lot of value though?
  • marcus_holmes 5y ago
    I think it's more that the "10x programmer" myth has caused a lot of pain and bullshit. There are startup CEO's who won't settle for anything less than a "10x programmer" and waste everyone's time trying to find one. There are narcissistic coders who think they're "10x" and therefore can act like spoiled children to everyone around them. If I hear "10x programmer" in anything other than "...is a myth" then it's a sign that whoever is speaking is probably someone I don't want to work with.
• khalilravanna 5y ago
  This is a great list. My two from 10 years of experience would probably be: - Simplicity is everything. Complexity is fun but business is not about fun. It’s about solving problems. It’s about having other people be able to read your code and quickly understand it. Or having a system that can be debugged without a PhD in the specific tool you’re using. - Everything is a tradeoff. If something feels too good to be true it probably is. If it’s easy up front, it’s probably hard in other ways. If you want to make something faster you’ll probably need to make it more complicated.
• shantnutiwari 5y ago
  Agree with most of this. > 1. I still don’t know very much Same here, Im still realising how much I dont know. > The 10x programmer is a silly myth. Yes it is. It's a stupid harmful myth. Everyone on HN and Reddit think they are the "10xers", and its used as an excuse to be rude and insufferable. Some time ago, I decided I'd be happy being a 1x programmer[1] > Don’t mistake humility for ignorance Very true. Some of the best engineers I worked with, those who would never get job at these 10x companies, were quiet and reserved. But when you actually talked to them, you realised it was humility and a willingness to learn. > Interviews are almost worthless for telling how good of a team member someone will be Yes, interviews are just a form of hazing. The survivors are those who can stand the hazing, not the best programmers 1. https://new.pythonforengineers.com/blog/confessions-of-a-1x-programmer/ https://new.pythonforengineers.com/blog/confessions-of-a-1x-...
  • Fordec 5y ago
    The 10x exists, I've met and worked with him and it's not me. But it is a guy who graduated Stanford before he could legally drive a car, so good luck finding many like him. But yeah, if I had to use a word to describe him, humble would fit.
  • btheshoe 5y ago
    Wow, you are a great writer though. Love your blog!
• mherrmann 5y ago
  > Software engineers should do anything that requires them to keep their written communication skills sharp. In my opinion, code is nicest when it is written communication. When it is almost the same as teaching someone about a problem domain.
  • CRConrad 5y ago
    > In my opinion, code is nicest when it is written communication. When it is almost the same as teaching someone about a problem domain. In a way, code is "teaching" the computer how to do some specific task in some specific problem domain. Fortunately, we know how to do that; it's what we do all day. It's just that the computer is a very dumb pupil, so it needs everything explained to it in detail. OK, no problem, so we explain in detail. We know how to do that too; that's still what we do all day. The next thing is, the computer is very literal-minded, has an excellent memory, and no imagination or sense of "the whole picture". It has absolutely no problem with us calling everything "i, j, k..." and "x, y, z..." But people do; in that sense we're pretty much the opposite of the computer. If only we could remember to call everything something more precise than "i, j, k..." and "x, y, z," the same "explanation" -- our code -- would be much more comprehensible to humans, too, and work as communication not just with the computer but with other people, including ourselves at some later time. (Albeit a rather tedious and detailed explanation, since most humans aren't as dumb as the computer.) That's (probably, IMO, at least in large part) why "Naming things is the most important problem in computing".
• dom96 5y ago
  This is a great list, I often wonder how people come up with such lists. Is it a long-term conscious effort to write down points like these as they come to you or do they sit for a few hours and these points come to their mind. I can't imagine being able to compile such a good list in a day.
• deleted 5y ago
  [deleted]
• journey_16162 5y ago
  > The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. I think the 10x programmer myth was never about productivity. The idea is more about creativity. I.e. one creative programmer can create a product that would have never existed otherwise.
  • ugjka 5y ago
    the dot com boom is over, you can make the next apple or google from your garage any more. All the low hanging fruit have been picked...
• lukaslalinsky 5y ago
  I'd say the top lesson I learned is that when you get a list of requirements from someone, most of the time they are not 100% set on them and if they agree to change something very minor, it can allow you to create significantly simpler solution and all parties will benefit from that. Junior developers often get lost while trying to design a super complex system, which satisfies all the requirements, while it doesn't really need to be that complex.
• everybodyknows 5y ago
  > Good written communication is one of the most important skills for any software engineer to master. But there is no "mastery" -- lifelong effort is required from all of us, especially to avoid falling into fashionable bad habits of the moment propagated so vigorously by our social media. > ... good of a team member ... "The word 'of' often intrudes where it does not belong, as in 'not that big of a deal'" - Garner's Modern English Usage, 4th edition, page 647.
• wallflow3r 5y ago
  Thanks for taking the time to share your experience. I appreciate you starting with context and the sections about innovation and data had me laughing.
• jimt1234 5y ago
  The one thing I've learned in software/computers: The more I learn, the less I know. To survive in this field, one has to accept the fact that everything he/she's worked so hard to learn and master is gonna be replaced by something new in a few years. Don't fight it. Embrace it.
• unobatbayar 5y ago
  The sad realisation that I'm the 0.1x software engineer.
  • halfmatthalfcat 5y ago
    Maybe software engineering isn't for you? Not judging you but if you admit to being 0.1x, why continue to do it?
    • unobatbayar 5y ago
      I really hope software engineering isn't the problem. I love building software; Thinking about creative solutions, trying to apply the right design pattern in the right context and all. Seeing myself in 3rd person, the main reason why I'm 0.1x engineer is attitude/motivation problem. Not having power over specification/design, reading bad code, seeing a bad UI specification, or when my code doesn't work is enough for me to start complaining, getting super pissed and not get anything done. I just can't work for other people, and really believe if I leave, many people would have the biggest sigh of relief.
• ipaddr 5y ago
  "Nothing worries me more than a senior engineer that has no opinion of their tools" Nothing worries me more than the opinioned. Open your mind. You shouldn't have deep opinions on your tools because they change, your need and understanding of them changes.
  • CRConrad 5y ago
    > You shouldn't have deep opinions on your tools because they change, your need and understanding of them changes. What's the problem with that? Opinions can also change.
• brightball 5y ago
  It’s rare that I see a post where I agree with it enough that I probably could have written it, but here we are.
• spion 5y ago
  > they’ve formed opinions about the way things should be I feel the opposite. I'd rather have no opinions rather than have strong opinions that prevent me form seeing new possibilities. Infact, I work hard on keeping my opinions under control.
• Graffur 5y ago
  > 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be I don't like this one. IMO it tells you nothing and assumes everyone shares the same culture of pushing opinions.
  • CRConrad 5y ago
    > > 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be > I don't like this one. IMO it tells you nothing and assumes everyone shares the same culture of pushing opinions. I like it, and think it tells you a lot. It doesn't say they have to be pushing their opinions, just that they should have some. And honestly, can anyone really know a lot about something and not form an opinion about it? Ask someone, "So, what do you think about ...?", and if their answer is "I don't think anything about it", then most likely you know that yeah, they haven't thought about it.
• RNCTX 5y ago
  Speaking of iteration, iterating over the most popular replies to this tells me that the points which hit home enough to drive engagement are replies to the effect of: 1) "No, my 37 day interview process is good, actually." 2) "Rails sucks" 3) "Making a thing people would want to use is a bad idea." 4) (two long threads) "The 10x programmer exists, I saw him once at a con." 5) "No one cares what anyone else thinks." HN really does represent the finest that the largest corporations have to offer. The proof is in the pudding.
  • shoo 5y ago
    There's also a path-dependent local optimisation aspect to HN comment threads. All things equal, threads that are higher up the page during the right time window get more eyeballs and more engagement, which might encourage people to hang their replies off the currently-popular thread. If we reran the "experiment" under essentially the same conditions we might find that a different bunch of responses get the most engagement.
    • RNCTX 5y ago
      It's still reflective of reality though! If I know one thing from working for large corporations, it's that whatever is talked about the most will never change.
      • therealdrag0 5y ago
        Aand there’s a segue back to the current discussion. There was a thread about “people don’t actually like innovation”. :)
• kevmo314 5y ago
  > "6. Sometimes you have to stop sharpening the saw, and just start cutting shit" Yeah no kidding. I learned how to write code in notepad but now it's like what happened to me :(
• pizzaknife 5y ago
  this one got me "10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers" - preach
• taylodl 5y ago
  I've been developing software for decades and here's the most important thing I've learned: systems will be around running for far longer than you ever thought possible, even when you allowed for systems being around for far longer than you thought possible! Keeping that in mind, I'm continually amazed at the number of developers who just love complexity. Don't get me wrong, they all profess to strive for simplicity but their work betrays them. They just love intricate dances carefully coordinated across several components, never minding how anyone 5, 10, 15 or 20 years down the road will ever comprehend this madness or how it will ever be maintained without incurring exorbitant costs. I religiously adhere to the KISS principle - Keep It Stupid Simple. Once you think it's simple look for ways to make it even more simple. Think about operations failing at the worst time of day possible on the worst possible day of the year - how will you quickly find and resolve the issue? What if it's a new hire who gets the call? I'm just amazed at how developers gloss over this, all while bitching about the "spaghetti code" they inherited. It boggles the mind.
  • lowercased 5y ago
    In 2017 I had someone call me and say "the system's broken". I knew who it was, but didn't know what they were referring to. Turns out it was a web application I'd put together in 2003. 14+ years later, it wasn't working, and... they needed help. I went spelunking a bit in my own code, cursing the jerk who built some of it, praising the genius who put in other parts, remembering cutting certain corners to get home for dinner on time, etc. Having to support anything 10-15-20 years down the line gives you a different perspective on maintenance and simplicity that I don't think you can quite ever really comprehend beforehand.
• maerF0x0 5y ago
  > 19. Interviews are almost worthless for telling how good of a team member someone will be I've been pondering the wisdom of having engineers do interviews at all. Interviewing, and getting someone to reveal their hand to you, is a massively specific skill, one that few get good at, let alone software engineers. Why is it that we think a 2 hour course on ethics and STAR can make someone capable of telling the difference between a con artist and a genius? I do wonder if having a professional hiring team to dig into who the person is, and then just trial them for competence would be a superior strategy?
  • ipnon 5y ago
    My Markov chain hiring process: Flip a coin. Heads, hire them on the spot. Tails, give them the usual guantlet of algorithm problems and coding challenges.
• UncleOxidant 5y ago
  "1. I still don’t know very much" I've been in the game for almost 30 years. I often feel like I know less than I thought I did 25 years ago, and that I know less as time goes by. I'd also have this as my #1 on the list because it just feels so surprising. I think most of us start out in our 20s thinking that in 30 years we'll have mastered the field, but it definitely doesn't feel like that, not even close.
  • ipnon 5y ago
    The domain of software engineering has almost certainly increased in size and complexity faster than any of us have learned. We must focus on the fundamentals. All of the new languages and architectures are a storm hovering over a bedrock of empirical computer science.
    • UncleOxidant 5y ago
      It's not just all the new stuff that's emerged in the last 30 years. I feel like I didn't really understand a lot of the fundamentals like I thought I did back in my 20s and that there were some major holes in my education that only became apparent after some years of experience in the field. Often you don't know what you don't know. I now know there's a lot I didn't (and don't) know and I think that's a valuable thing that mostly only comes with experience.
• khazhoux 5y ago
  Anyone who denies the existence of the 10x programmer has either simply not encountered one, or is blinded by their own ego. In my 20 years in industry, I can think of maybe 10 engineers I've directly worked with who were an order of magnitude above all their peers in terms of both code volume AND quality. These are people who will implement a feature with clean code, well commented, well thought-out and meeting the exact need, correctly structured, in the time that the entire rest of the engineering team would still be scratching their head and debating what to do. One guy years ago who refactored the entire backend at a startup in 2 days, then asked "OK, what can I work on now?" Another guy who wrote an IPC system we needed, which I'd expected would take us 6 weeks, and he did it over the weekend (and it worked perfectly). Another who debugged and patched a critical infrastructure problem in a very complex system, in about 2 days... and would do this time and again, just cranking out features and fixes, week after week. * "Oh, but their code must have been rushed!" It was fast but not rushed. Some of the best code I've seen. * "Oh, but they didn't consider user requirements." They did. * "Oh, they must have been insufferable to work with!" For the most part, super friendly and great teammates. And so on. So, sorry if it offends, but some people are just much better developers than everyone else around them (including, possibly yourself). I was much happier after I realized and accepted this fact!
  • deleted 5y ago
    [deleted]
  • beebmam 5y ago
    In my 20 years of industry at both small and large tech companies, I couldn't disagree more with you. I'd also appreciate if you toned down the insults.
    • khazhoux 5y ago
      It should not be an insult to be told that there are people more skilled than you, though. It is hubris to think otherwise. Are you saying in 20 years, you haven't met any engineers that were head and shoulders noticeably more productive than their peers, in terms of code volume+quality?
• tshanmu 5y ago
  4. The best code is no code, or code you don’t have to maintain 5. Software is a means to an end these x1000! Thanks for a very succint, distilled list.
• blindmute 5y ago
  >The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. It's not a myth, or silly. It's not even super uncommon.
• deleted 5y ago
  [deleted]
• mandeepj 5y ago
  > We should be far more focused on avoiding 0.1x programmers than finding 10x programmers I disagree here. A 10x programmer (or whatever other metric you want to use) brings a high level vision and uses that to turn around things faster like building Dynamics UIs, automation, or other tools.
• wnevets 5y ago
  There are so many items on this list that I've internalized over the years and this has done a great job breaking them down into a paragraph of text.
• neves 5y ago
  As Very nice advice. I really like this phrase: "I’ve seen a lot of systems where hope was the primary mechanism of data integrity. "
• mixmastamyk 5y ago
  > Sometimes the noisiest people are the ones we want to listen to the least. Yes, especially umm... everywhere in life. `s/sometimes/most of the time/` > Sharks, not dinosaurs Gonna remember that one, thanks.
• mooreds 5y ago
  I loved a lot of this list, but the best part was the disclaimer in front. I've given talks about software development in the past and usually start with a similar disclaimer. If I am giving you advice, you should know my context. It'll help you determine if my advice is useful in yours. Bravo!
• protomyth 5y ago
  Enterprise Software is at the mercy of every bureaucracy that the enterprise must deal with and the interactions between bureaucracies can create incredibly complex non-logical logic. Just remember, at one point every gallon of biodiesel in the US had its own serial number.
• brabel 5y ago
  > You can design the most technically impressive thing in the world, and then have nobody want to use it. Happens all the time. Very true... just yesterday someone posted about the Pony language main user switching to Rust: https://www.wallaroo.ai/blog-posts/wallaroo-move-to-rust https://www.wallaroo.ai/blog-posts/wallaroo-move-to-rust Despite Pony being an impressive programming language, technically, with a lot of promise, pretty much only one company ever used it and now that it's moved on, Pony is pretty much in the camp "no one uses it". And much of it is serendipity. A few tiny things could've happened differently, and now everyone would be talking about Pony, not Rust. Similarly, perhaps, happened with Ceylon (anyone remembers that??) VS Kotlin.
• begueradj 5y ago
  "If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system" That is what the "old" models such as waterfall say: as a first phase, complete and accurate software requirements list to be captured in a product requirements document
  • dgb23 5y ago
    You are conflating process with design. You can have an iterative process and still take time to think, design and specify things.
    • CRConrad 5y ago
      > You can have an iterative process and still take time to think, design and specify things. Start with some thinking, designing and specifying, then start implementing from that -- but remember to take the time for some more thinking, designing and specifying throughout the process going forward. (Not disagreeing, just "spelling out". Hm, is this my new personal definition of "Agile"?)
• pjc50 5y ago
  This is a very insightful list. But there is one thing I'd quibble with: while it's inherently a super-subjective metric, I would say that 10x programmers do exist. Both in the "can support a company by themselves" sense and the "mad lone genius" sense. Not all the 10x programmers are good at working with other people or on other people's ideas. 0.1x programmers are often lost or afraid, although they may just be unimaginative. The real risk of fear is introducing 0.1x processes. People are often willing to sacrifice any amount of development velocity to avoid being seen to make mistakes. Sometimes this makes sense, sometimes it doesn't. Arguably the reason for the success of SpaceX is that they were willing to fly, crashland, and improve a dozen rockets in the time that a conventional company would spend agonizing over whether to launch at all. On the other hand, nobody wants to be on the same roads as the "move fast and break things" self-driving car.
  • AlexCoventry 5y ago
    I think he's beating up a straw man, here. > The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. Over such short time scales, maybe, but the idea that someone could contribute in 1 year what another programmer wouldn't accomplish in 10 years is highly plausible, to me.
  • fouric 5y ago
    > while it's inherently a super-subjective metric, I would say that 10x programmers do exist Even worse than super-subjective, it seems like people don't agree on the definition of "10x programmer". Is that 10x value (code * code quality) produced per unit of work-time? Per brain cycle? Are you controlling for programmer experience, or domain knowledge, as [1] pointed out? Do you actually mean 10x, or is that a stand-in for "significantly more productive" with an unknown value? Do you include collaborative skills and working with a team, or even entirely base your definition off of that? I'm both curious as to the exact definition you have in mind, and also trying to point out the more general issue so that others arguing past each other can realize that they have two different ideas in mind. [1] https://news.ycombinator.com/item?id=28797923 https://news.ycombinator.com/item?id=28797923
• agomez314 5y ago
  "We may be the culmination of our experiences, but we view them through the lens of the present." This is so important. I think a lot of the advice given out there comes with the bias of having been successful doing it. There are countless others who have tried to scale the same ladder, doing the same things even, and still did not achieve the same success.
• ChrisMarshallNY 5y ago
  I like the advice (and the "context" caveat, at the start). > The best code is no code, or code you don’t have to maintain I always say "The best code I write, is the code I don't write."
  • janto 5y ago
    I always say "code is a liability".
    • ChrisMarshallNY 5y ago
      I remember seeing a .sig someone had, that said something like: I hate code, and want as little of it as possible in my programs.
• austincheney 5y ago
  Point 12 is objectively the most true in practice. In my 20 years of experience quality of software engineer comes down to personality, the ability to make decisions based upon evidence more than intuition and the ability to make decisions in the face of insufficient evidence. There is a certain vision of systems that cannot be taught as many people are incapable of accepting concepts of economic abstractions outside what they can put their hands on.
• cryptica 5y ago
  Amazingly, I agree with every single point. >> Nobody asks “why” enough This point is the most important IMO. It's so common for people to do things without asking themselves why they're doing it. Every line of code should fulfill a clear purpose. You want to avoid writing code which is difficult to explain to a non-technical person. >> People don’t really want innovation... If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle. This sounds ridiculous at a glance, but it 100% matches my own experience in pretty much every company and project I've ever worked on. It applies to everything; jobs, getting funding. Nobody wants to see real innovation and nobody wants to see real talent. If you're too good as a developer and innovate too much, developers who work for big companies will get jealous and they will reject you. If you're very good, you need to pretend to be mediocre and above all; compliant.
  • dustintrex 5y ago
    I think "jealous" is not a useful lens here. People reject innovation because genuinely changing the way the way they have to do things is painful even if the attempt fails, and will probably lead to some people losing their jobs if it succeeds.
  • prancer_or_vix 5y ago
    > developers who work for big companies will get jealous and they will reject you. If you're very good, you need to pretend to be mediocre and above all; compliant. To add to what another poster said, it's not jealousy. Big companies move slow because generally, to get big, they had to be successful (to some extent) and changing too much all at once is a risk that the bureaucracy isn't always comfortable with. One of my old managers (I work in "enterprise") used to say things like "the efficiencies that this solution will bring the company..." which was just a euphemism for more folks getting laid-off (happened all the time, and glassdoor was full of warnings about this) or more jobs being shipped to our offshore units or even down-sizing in our offshore units. I think it's reasonable, at least in the US, where healthcare & retirement & welfare is so tightly coupled with employment, for folks in big companies to be wary of innovation. They might want their job to be easier, sure, but too easy and they could be out of a job (for example, if the workload that previously took 5 people can now be managed by 2 or 3). We're building software for people.
• RayVR 5y ago
  The 10x programmer discussion feels a bit silly partly because it’s on the wrong scale. The real scale is more like this: In a specified amount of time, N, what is the conditional probability that the engineer, e, can design and code a solution which is (relatively) error free? This shifts into [0, 1] and is really asking the more important question.
• elihu 5y ago
  > "The only way someone can be a 10x programmer is if you compare them to 0.1x programmers. Someone who wastes time, doesn’t ask for feedback, doesn’t test their code, doesn’t consider edge cases, etc… We should be far more concerned with keeping 0.1x programmers off our teams than finding the mythical 10x programmer." I think I would add to that that 0.1x programmers are to some extent a product of their environment. Maybe there are people who are inherently 0.1x programmers and there's nothing anyone can do about it, but I think it's also the case that the local engineering culture can turn people into 0.1x programmers. So, the important thing is to figure out how that happens and don't do it. Some examples: make people do arbitrary repetitive tasks. Hide information. Make infrastructure changes frequently to the point where people regularly have to ask "how do I do this important job function today?" Create domain-specific languages and don't document them. Use build systems that don't work reliably. Have CI systems that require users to wade through megabytes of errors to find the one line that failed. Invent new words for things, or use old words in creative new ways. Speak in acronyms. Create technical documentation (if at all) that never explains "why". Don't set aside time for training. If a question warrants a one-sentence answer, filibuster for ten minutes to prevent follow-up questions from being asked. If it warrants a ten minute answer, reply with a sentence. Especially if you're in a very different time zone, and every follow-up question adds 24 hours to task completion time. Treat "programming ability" as some immutable attribute that is conferred on developers by completion of a bachelor's degree in a computer-related field, and that these programmers are interchangeable and their skills always current and directly applicable to the task at hand. Create Byzantine labyrinths of web-based tools that none can navigate without first having been shown the way through.
• codedeadlock 5y ago
  Great advice. One of the things that I have learnt is how important effective communication is for software developers. It can make or break the products.
• revskill 5y ago
  Programming to an interface rather than the implementation is the only rule to me.
• sunnyday1337 5y ago
  I have seen many similar posts what people have learned but not once have I seen: "Don't assume anything". So many times when shit hit the bricks because someone assumed something about some other thing they clearly don't know everything about. Which eventually lead to the system failing.
  • pydry 5y ago
    It would be impossible to do any work at all without making assumptions. This attitude belies the fact that of the 1000s of assumptions you make every day 1 or 2 will end up being incorrect, but it's usually very, very hard or even impossible to know which in advance.
    • Aeolun 5y ago
      It’s fine when you don’t do it deliberately. It’s just that about 100% of the time someone says “I just assumed…” that is the source of whatever problem you are having.
    • danparsonson 5y ago
      Yes the point would better rather be made as "continually question your assumptions" especially when troubleshooting (hence the value of having a rubber duck).
      • pydry 5y ago
        The original point is invalid, although one could say that being good at systematically validating and invalidating assumptions is the sign of a good engineer. One who doesnt make assumptions at all just wouldnt do anything, though.
        • CRConrad 5y ago
          I assume that when I press a key on my keyboard, the corresponding character will show up in my code editor. If I couldn't assume that, I doubt I'd see the use of pressing any keys at all. (For clarity's sake: Not disagreeing at all, just illustrating your point with a reductio ad absurdum example.)
• boffinAudio 5y ago
  40+ years of experience here, and I'll tell you the #1 thing I've learned: * Software is a social service. Its for other humans. Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in...
  • zanethomas 5y ago
    another 40+ here w0rd!
  • gjvnq 5y ago
    > Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in... That's probably because many devs were socially isolated when growing up. (How do you think they got so much time spent tinkering with computers?) Also, it is generally hard to imagine yourself in other's shoes. Example: imagine trying to use your UI but with a 60-year old vision instead of that of a 20-yo. Example: imagine having no formal address or no citizenship (stateless).
  • chaps 5y ago
    I do a lot of dev work with non-profits and such. About a year ago I was working on an extremely difficult project as a volunteer where I was insistent that a specific part was vitally important to getting the project to move forward (generalizing tables extraction from scanned OCR docs) and I was spending a lot of time on it. One of the devs I worked with, with 40+ years of experience, basically told me this exact thing. He argued that what I as working on was a waste of time and that I shouldn't work on "code golf" problems, because of the likelihood of failure and that ultimately I should consider the human side of the problem. He said it was best to work on other things instead. Fast forward a month later, I managed to actually do it, and it worked almost flawlessly, across about 100k scanned PDFs. Multiple long-term projects spawned off from the extracted information, including some projects from the dev who told me to stop. My point being -- sometimes it seems like that line is used as an excuse to not tackle hard problems if they seem likely to fail. I agree with the line, and it's the exact reason I worked on it as hard as I did, but the dev failed to consider that I understood the social part of the problem, on experienced principle.
• vishnugupta 5y ago
  > 13. Your data is the most important part of your system +1. Most (including me) internalise, if at all, this lesson the hard way through trial and error. I wish this is was taught in colleges. Software is mostly about manipulating data and it's a pity that not much is taught in a structured manner about building systems around data. I expected Domain Driven Design (DDD) would address this but it doesn't.
  • JackFr 5y ago
    Thirty years ago at my first job, a senior dev told me "2% of what we do is interesting. 98% is sort, select, sum." (I think then that was more or less true, but the numbers in the industry as a whole have gotten a lot better in the past 30 years. And I've gotten better jobs.)
  • Aeolun 5y ago
    It is taught. And then you enter the real world and you find that everyone just ignores this shit whenever it is convenient (and unsurprisingly the data is garbage).
  • brianmcc 5y ago
    Agree. This is one hill I would choose to die on, data is so much more important and valuable than code. Database design - normal form, relations, etc - was a major part of my education. Surely that's not unusual?
• naruvimama 5y ago
  > 11. ..... > Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. The more you learn the more you realise you were wrong. Having an opinion has often come to mean one is a fan boy of something and will have it no other way. I have heard team leads say "this python code is bad because it uses no classes" or "we need to use EMR so we can process all customer data together" Bad opinions formed can be dangerous and counter productive. Though I do agree that an opinion based on having a well thought out plan and experience is a sign of maturity.
  • MaxBarraclough 5y ago
    Right, there's a big difference between an engineer with well-founded opinions, and a fanboy with strong emotions. If you can't explain the weaknesses of your favourite tools, that's not a good sign. If you can't explain your preference for one tool over another, that's a bad sign. It's disappointing to encounter developers who, for example, love C# but hate Java, and are entirely unable to articulate why. They're very similar languages! Somewhat related: Rich Hickey (of Clojure fame) makes the point that one of the disappointing aspects of the software development community is that there's so much talk about 'better', and so little about trade-offs.
  • jgilias 5y ago
    I think that there is a very important distinction between having opinions, and willing to have it 'my way only'. I subscribe to the 'strong opinions, weakly held' model. It's necessary to have opinions about things you're involved with. However, the real art is to be able to not be too attached to one's opinions, be open to change them, and be able to be a productive team member, even if there is a decision to do things in a way that doesn't conform to one's opinions even when the opinions haven't changed.
  • jrimbault 5y ago
    I think points 11 and 15 (Don’t mistake humility for ignorance) play of each other. I don't have a hate/love opinion on most things. I may have an opinion on wether or not one particular technical choice is contextually a good or bad idea. I may not be able to form an opinion.
• jimmyvalmer 5y ago
  Perspective by definition is something that requires time, so any top 10 list of this kind can't be applied consciously with any rigor. I will say point 12 (everyone loves cheap wins, and hates substantive progress) is unadulterated (but unactionable) truth.
• deleted 5y ago
  [deleted]
• ctrlp 5y ago
  This is a great list. Really appreciate all the experience.
• wccrawford 5y ago
  "Interviews are almost worthless for telling how good of a team member someone will be" Just like "avoid the 0.1x programmers", interviews are for weeding out the really bad team mates. They aren't for finding the best ones. For instance, I and a female programmer do the interviews. During one interview, my coworker kept asking questions of the candidate, and he would not look at her when he talked. He would actually talk to me instead while answering her questions. My first through was that he was misogynistic, which is an automatic disqualification. But even if he was just shy, he's going to have to work with her daily for the first few months, and be in meetings with her for the entire time he worked there. That's an extreme example, but there were plenty of instances where we were looking for the best candidate, and the interview made the decision easier when the code hadn't. We can only hire 1 candidate, and we have to do what we can to pick the one that will do the best work and get along best with the team. That's what interviews are for.
  • CRConrad 5y ago
    > During one interview, my coworker kept asking questions of the candidate, and he would not look at her when he talked. Or maybe he just thought she looked hot, and was afraid of appearing to be ogling her too much. Sometimes people fuck up by trying too hard not to fuck up.
• cbovis 5y ago
  Excellent advice. I would add: Showcase your work as much as possible and refine your ability to do so over time - Not only does regular showcasing of things you've built improve your reputation within a company but also allows you to disconnect from the implementation and focus on how something will be used. You'll often find bugs, shortcomings, or opportunities for improvement that you may otherwise have overlooked. Look for opportunities to showcase wherever possible and advocate for opportunities if they don't exist already.
• goodpoint 5y ago
  20 years of experience here. My little contributions: 21. Do not mistake hype and popularity for quality. 22. The best code is no code, but configuration is worse than code. Maintaining 1000 lines of YAML is worse than 9000 lines of code. 23. The best code is no code, but replacing a script with a zoo of tools and libraries is often worse.
  • marcosdumay 5y ago
    The best code is no code; the second best code is high quality third party code; the third best code is your code; the worst code is low quality third party code, and that one is by a huge margin.
    • goodpoint 5y ago
      Nicely put. Yet I would add that your code is preferable to third party code if you can solve the same problem with 10x less SLOCs or complexity.
      • marcosdumay 5y ago
        To change a completely misunderstood citation into a new one that nobody will understand either: > Unnecessary flexibility is the source of all evil Just as with the original "premature", the word "unnecessary"is doing a lot of heavy lifting here, and there's no way to state that rule that saves people from thinking before applying. Some times those 10x SLOC are really important and will save you; most times it's just a 90% waste ratio multiplied over your previous one.
  • dgb23 5y ago
    I think I somewhat disagree with 22. Not specifically in terms of YAML or what is categorized as configuration (basically anything?). I think a well designed data model is much more productive and simple than arbitrary code.
• DrBazza 5y ago
  21. is that management cannot, will not, and will never understand why open plan offices are the worst for reducing productivity. You don't want the plebs to also have their own offices.
  • commandlinefan 5y ago
    22. no matter how well you plan, as soon as the (completely arbitrary) deadline gets close, everybody - even people who know better - will demand that you throw in last-minute hacks at 10 PM to "fix" a problem that nobody thought of before that create technical debt that will never be paid off and will be blamed on you.
• quadcore 5y ago
  The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job. So let me give one advice: you are not producing code, you are engineering code. Some will find solutions that the others will not find. Thats where the 10x programmer thing come from. The guy who wrote bittorrent said something like the following: "I've written bittorrent in a way you would never have thought about". You think John Carmack was the only one trying to make 3d games when Doom came out? Thousands of programmers where trying to. Does that make him a 10x programmer in your opinion? Or more like a 1000x?
  • hooande 5y ago
    You don't say that so-and-so is a "10x painter". Art is obviously not about the quantity of paint used per day, but how it gets used and in what context. This is what you seem to be communicating with your quote about bittorrent. Because we're programmers, we chose an empirical measurement ("10x") as our term for high skill. This terminology is confusing and stupid, but now we're stuck with it
    • jimbokun 5y ago
      I'm guessing there are clearly 10x painters other painters can identify, but there are even fewer quantifiable metrics to measure a painter's output than there are for programmers.
  • faizshah 5y ago
    This is the opposite of how you should want any knowledge worker to think. If you believe that there’s some innate ability that makes people 10x better at a skill than you rather than hours of practice and study then you are much less likely to acquire that skill or learn those skills efficiently. You need to have a growth mindset to be an effective knowledge worker not a fixed mindset. This is discussed in the book Make It Stick on learning science, in chapter 7 they discuss how your own views on whether skill is innate vs the result of practice affects your own ability to learn and grow.
• SMAAART 5y ago
  Not a Software Engineer here, but in Operation here: 1. This is great advice 2. The overall spirit applies to any and all roles across any company. 3. YMMV
• Tade0 5y ago
  10. I don't think the bottom end of the scale is zero. I've seen people being actively harmful to the project. That being said where you lay on the scale depends on context. In my previous project I was a [-0.25;0.25], so I quit, because I was miserable and so were my teammates who had to work with me. Now I'm doing great and even helping others be more productive.
• jjice 5y ago
  I liked 8 a lot > Every system eventually sucks, get over it I'm a fresh recent grad developer, and this is good to know to calm me down from over architecting. I'll do my damnedest, but it's to know it's not awful if things get a bit messy eventually.
  • dgb23 5y ago
    A better way to phrase this is that there is always room for improvement but we don't have infinite time. Deciding what to improve when is a skill.
• scottious 5y ago
  > I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. I've been a developer for 15 years... anybody else feel like the further they get into their career, the more they want to keep their opinions to themselves? I feel like as a junior dev I had way stronger opinions and I was a lot more vocal about them. Now, I still have opinions, but I've learned that nobody gives a damn about my opinions so I just keep them to myself.
  • JackFr 5y ago
    I got dinged in a 360 review by peers for not advocating for my views more. I feel that if I present what I think we should do, and why I think it's the best alternative, I shouldn't have to get into a shouting match or even a debate. I don't take it personally if people disagree with me. If I've got the best ideas and my managers are ignoring them for the loudest ideas, that's on them, not me.
    • noisy_boy 5y ago
      Maybe they are pissed that they cant drag you in the failures by saying "even X had the same opinion..."
  • allenu 5y ago
    Same here. Been working professionally as a dev for 20 years and each year I care less and less about changing other people’s minds about architecture. Just this year I was working with another team that wanted to move to an architecture that I thought was overengineered for their specific problems. They shared with me an article about some company that was using it. I explained my experiences with such a pattern and where the pitfalls were, hoping their lead dev would think about it or discuss the pros and cons. Well, it was met with silence. They went ahead with their plan anyway. Too many times that’s happened in the work world, so at least now I don’t invest a lot of effort into changing minds. Best advice I’ve learned these last few years is don’t tie yourself to your work. If you’re opinionated about how to do things because you love designing software, that’s great, but you’re setting yourself up to be disappointed by how things really get done.
• johanneskanybal 5y ago
  Similar experience and life path, agree with each one of these really, very valuable. The silly 10x argument which is quite prevalent around here especially, probably says a bit about the audience.
• aehlsf 5y ago
  Reinventing the wheels lol it’s everywhere. Not just in software engineering field. Some people do it to look busy and others do it to keep employed! Thanks for sharing your wisdom. I have enjoyed reading your writing.
• throwaway984393 5y ago
  > 20. Always strive to build a smaller system K.I.S.S. is a great principle, but inexperienced devs really have no way to understand what is small/simple and what isn't. If you find yourself doing 3 unrelated things before you can finally get to the one thing you were meant to be doing, it's probably already too complicated. If you build it really simple, it can look under-designed, or inefficient, or out of date. But if you find yourself thinking, "this would be better if it were a little bit more complicated", you might have just hit the sweet spot.
• l2cluster 5y ago
  > 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be I found that another thing which separates a junior from a senior is tendency to give up and cut corners. Stuck a wall making that integration test work? get back to it after the current task, don't settle on manual testing. But maybe that's a trait of bad developers, rather than junior ones.
  • sdevonoes 5y ago
    Umm, I don't agree (with OP). Senior (or juniors, if it matters) engineers who have strong opinions about anything are, in my limited experience, very stubborn and difficult to work with. I find myself more and more answering with "it depends, give us more time to see what can be done/what tools we can use".
  • axegon_ 5y ago
    I really disagree with point 11. I've seen and worked with so many "senior" engineers who had wretched opinions about everything. One thing in particular is what I like to call "perl behavior". The structure and logic makes perfect sense to the developer but is borderline gibberish to anyone else. Eventually senior software engineers enforce their view as the baseline(which is over flooded with anti patterns) to junior developers and they too end up pouring buckets of the same gibberish everywhere. For example custom built linters which partially follow some standard, and partially doing the complete opposite of what the standard says. But you know... The senior engineers enforce it and 2 years down the line when the junior jumps into another job, it's back to the basics all over again. Anyone with X number of years of experience has strong opinions, that does not make anyone "senior". To my mind, point 11 should be the ability to consider, shift or change your strong opinions when presented with an alternative.
• n_time 5y ago
  Wish there was more philosophy of science and exploration into what "technology" means in CS programs. Maybe get undergrads to read Crime and Punishment by Foucault. Not saying he's the be-all end-all but just that perspective of seeing technology as subjective and situated in historical contexts. Technology in CS ends up instead being taught to be magical progress fuel that brings us towards the inevitable future rather than tools built by people with access to capital in order to achieve specific ends
  • beaconstudios 5y ago
    I feel that programmers in general have a lot to learn from the postmodernists. Learning about social constructivism alone can teach you a lot about how to think about abstractions.
• mrpotato 5y ago
  > 1. I still don’t know very much > “How can you not know what BGP is?” I learned a while ago that answering someone who asks you "What is X?" and replying with a phrase similar to the above is probably one of the worst ways to broach the subject. It comes off as questioning the person's intelligence/knowledge. Instead try to see it as a teachable moment. If it is something you think is cool and/or you are passionate about, you should be excited that you can show your friend/coworker something really cool. ie: "I've never seen Rick and Morty", "You are absolutely going to love that show. I know what you will be binge watching this weekend!" Anyhow, to put it bluntly, don't be a dick about it.
  • mehphp 5y ago
    I used to be pretty bad about this, and I honestly didn't realize I was doing it until someone pointed it out. I hate when people do it to me, so no idea why I was doing it right back.
• new23d 5y ago
  A relevant and a fascinating read is this recent paper by Barry M. O’Reilly titled The Machine in the Ghost: Autonomy, Hyperconnectivity, and Residual Causality [1]. > This article will examine the unnamed and potentially devastating constraining effect of software on human autonomy. I call this concept residual causality, where software design decisions made long ago in different circumstances for different reasons constrain human action in an unknown future. The less aware the designers of software systems are of complexity in social systems, the more likely they are to introduce residual causality." [1] https://www.mdpi.com/2409-9287/6/4/81/htm https://www.mdpi.com/2409-9287/6/4/81/htm
• tomxor 5y ago
  > Software engineers, like all humans, need to feel ownership I've always found this to be very true personally. Unfortunately fear often directly opposes it, i.e concepts like "what if that guy gets hit by a bus" which are valid but sometimes taken too far to the point of attempting to make everyone easily "replaceable"... i've a saying to warn of this that has helped me alleviate such fears in others so far: If you make your entire developer team replaceable, they will create code and products that are equally replaceable and hold no value. People are the company, they need to be valued as such.
• jart 5y ago
  > The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. The only thing about the 10x programmer saying that's a myth, is the assumption that it's a quality inherent to the person. You can absolutely accomplish the same level of impact in a week that might take a competent respectable colleague a year, and you don't have to be a genius to do it. You just have to have a good idea at the right moment. It doesn't even have to be a constant thing. In my career, sometimes I'm just a normal programmer and sometimes I do some bona fide 10x work. A lot the times the 10x work I get the most kudos for will be some absurdly simple low-effort yet impactful thing, like sending pull requests to projects that change a single line of code to bump up a version number in an xml file that has 0days. But because the idea is so simple and almost silly, I can do it a few hundred times and have more impact. Then I can take into consideration that many of these projects I'm fixing are libraries or frameworks, so I'm not only rescuing the project but rescuing their users too. That kind of transitive impact is what makes 10x possible. Programming isn't like a 19th century assembly line where labor had a very static measurable and manageable impact. Our culture is still catching up in fully understanding and internalizing the enabling impact that computers make possible.
• husamia 5y ago
  from 15 years experience. The best code is no code. I learned to say no 99% of the times. it works
• winternett 5y ago
  In my 22+ years of work as an Engineer/Architect, I've found that: 1. Software development skill means nothing if the power goes out, always cultivate other skills and passions, those passions will drive you to develop more meaningful, functional, and well informed tools. 2. My resume never parses correctly on the job application, no matter how big the company is, and I'll always have to retype it over again. 3. The level of functionality on each company's web site job application tool tells you everything you need to know about the development quality and talent within each company.
  • kreeben 5y ago
    >> resume never parses Every time I rewrite my CV I always think, finally it's picture perfect. Next time I revisit it, because I'm looking for another job, I always think, who the F wrote this piece of crap. I'm either slowly making progress or I'm running in circles.
    • winternett 5y ago
      I found a lot more success in the working world once I choose to just embrace the "normalcy" of certain things that routinely don't make sense in the working world, and to simply try to make what I can make work better. The working world is really nonsensical and absurd if you ask me, but the end goal of doing a job for money that in turn allows me to do things that "make sense" to me is the payoff. Self Sacrifice is sometimes necessary for success, but it is a finite resource, and can hurt or destroy you if not carefully applied (the simple equation) A resume just needs to show the mountains you've climbed against the odds, without lamenting about the battle scars you got along the way... Resume formatting is really just fluff, that you don't need if they need you because you've proven that you can climb real mountains. :P
• Sohcahtoa82 5y ago
  > “if they ask about time off in the first interview then they are never going to be there!” The fact that this attitude is common scares me when I'm doing interviews. Time off is incredibly important to me. What's the use of making a great income if you can't get the time off to enjoy it? The culture about the use of PTO varies wildly between companies. A friend of mine worked somewhere that supposedly gave 20 days PTO per year, but trying to actually use more than a single day at a time was always met with denials, and even if you did take a Friday off, you were expected to work 10 hours/day the other 4 days of that week to make up for it. So yeah, when I'm interviewing, I want to know how much time people are taking off, but I don't want the interviewer to think I'm lazy and will be trying to avoid work as much as possible.
  • brundolf 5y ago
    Yeah, if I ever discovered that a potential employer took this view of PTO then I wouldn't want to work there anyway. Huge red flag.
    • gregd 5y ago
      Small point: The author of the article does NOT have this attitude. He's calling it out as a bullshit attitude...FWIW
      • brundolf 5y ago
        Whoops! I should have read the article. Edited.
  • ghaff 5y ago
    This is especially true if the company uses "unlimited"/not-tracked/etc. time. Otherwise, unless you know someone at the place (and even then it can vary by group), you're left with making assumptions about norms that may not be accurate. Personally, I've never not used all my PTO in a given year and would consider being unable to do so a show stopper.
    • 5y ago
• dragonwriter 5y ago
  > The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. N× programmers for N>1 are mostly not N× cowboy solo code slingers, lots of gains are in enabling other members of the team. The idea that programmer contributions to output are all in solo code slinging is a close cousin of the myth “programmer contributions can meaningfully be measured in lines of code”.
  • ljm 5y ago
    At some point, you start to become effective not by churning out code faster than anyone else can do it, but by anticipating upcoming blockers and clearing them out before they become a problem for the team. You're able to use a holistic insight of the project to your advantage in order to keep the team's efficacy to a high level.
• legohead 5y ago
  most valuable lesson I've learned in 20 years: * companies and/or owners don't care about you. take everything you can get and don't be shy about it. don't listen to them when they continually tell you that you're "highly paid"
• agonmon 5y ago
  "People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty." This rings true from being at a Fortune 100 going through "digital transformation". So much jabber about "innovation" and AI / machine learning this and that, when what they really wanted was just to do what everyone else was doing, and just implement similar systems to what Amazon had done a decade+ ago.
• wallace01 5y ago
  Thanks, love the post. I agree with everything you said. Recently, I was in an interview for a company and they gave me three requirements for a versioning tool I should design conceptually. I started with the data models and then the backend / frontend communication. I wasn't told who this versioning tool should be for, how many people would use it and other important domain related things, so I said I'll concept a simple solution that would work fine for a group of people but would have to be refactored if we'd want to scale up and support thousands or more connections simultaneously, I was told "sure, go for it".. Once I finished I said that I was confident that a versioning tool has way more complexity and requirements than described initially within those three sentences and that 60 minutes to design such system in a stable way is optimistic. A week after the interview I was told that they don't want to continue with me because I didn't ask enough questions and that my solution wouldn't work if millions of people would use the system at the same time. I think I avoided a bullet
• yoyar 5y ago
  It was alluded to in the list but I like this great quote: "the best way to deal with complexity is to remove it"
• chown 5y ago
  > No one is going to tell you in an interview that they are going to be unreliable, abusive, pompous, or never show up to meetings on time. People might claim they have “signals” for these things… I had a great interview with one of the FAANG companies. The technical interviews, 6 of them in a row!, felt more like they were wanting to see me fail spectacularly rather than focus on my approach of solving whiteboard problems. Still, I did more than average to get "pass" from them. But HR dropped me because she didn't like the answer to "what's your weakness?" question along the lines of - "I focus too much on job at hand to an extent that I struggle with work-life-balance and working on it. If I can overcome that and learn how to take breaks timely I might be more productive.". HR didn't like it because it was not one of the canned responses she was expecting ¯\_(ツ)_/¯
  • hnlmorg 5y ago
    I remember recruiting one junior and the HR representative asked that "What is your weakness" question. Personally I hate it because it almost never returns an interesting answer. However on this one occasion the junior did proceed to list off several genuine weaknesses. After about the 3rd point he listed I had to stop him from talking. Ironically it was his honesty in that interview that won me over. For a junior role I'd rather than a rough diamond who I can shape than someone who already thinks they're perfect. And he turned out to be an incredibly good hire too. Despite being a hiring manager for many years, I still dread getting asked this question myself. It is easily my least favourite interview question. Even the "Explain an occasion when you disagreed with your manager" question is much more favourable than being asking "what is your worst quality".
  • xyzelement 5y ago
    >> I struggle with work-life-balance and working on it. If I can overcome that and learn how to take breaks timely I might be more productive.". .. HR didn't like it because it was not one of the canned responses she was expecting ¯\_(ツ)_/¯ Just curious, how do you know that (a) you failed in HR (b) that it was this question and (c) for this reason? I ask because it's unlikely that this was literally the feedback given you. Also, "I work too hard" does sound a bit canned. >> The technical interviews, 6 of them in a row!, felt more like they were wanting to see me fail spectacularly rather than focus on my approach of solving whiteboard problems. I do think this is more "in your head" that real. Nobody shows up to an interview wanting the other person to fail, but "how they solve whiteboard problems" isn't the goal either. It's more about - how does the person, think, collaborate, make tradeoffs and drives to an outcome - the goal being specifically to translate that outside the whiteboard space.
• quickthrower2 5y ago
  The main thing I’ve learned is there is a glass ceiling of pay as a SWE and although it seems to pay well, once you have a family to support its pretty much working class. Trying to make money in side hustle is futile for most (You are the commodity compliment to FAANG etc.). Investments are the way to go to increase comfort of living. Why all the money focus and not about craft and blah blah? Because you are a worker for a business. You will unlikely get to build your magnum opus at work and probably won’t have the energy to do that at the weekend (for most of us). So programming as a job is heavily about earning a living. Work hard, do a great job. If you are 10x then what are you doing working for someone else anyway? Are they paying you 1M a year?
• steve_taylor 5y ago
  12. People don’t really want innovation People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty. If you truly innovate, and change the way that people have to do things, expect mostly negative feedback. If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle. Ain’t that the truth. I’ve come up against this my entire career.