40 ms·

Things I’ve learned in my years as a software engineer (2021)

• mmcconnell1618 4y ago
  I love the idea of technological sharks roaming the software oceans. I've seen a few megalodons hanging around the mainframes too. Thanks for sharing a great list.
  • neilv 4y ago
    "That ancient billing run batch process is an optimal killing machine!" (It might even outlast us through climate change.)
• locallost 4y ago
  > Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. If you are using your tools, and you don’t love or hate them in a myriad of ways, you need to experience more Strong disagree. If you haven't found an issue with something you love, or a useful aspect in something you hate, you need to experience more. I don't know if I'm senior other than doing this for a while, but I had more opinions when I was starting out than now. I do have more clear opinions now in terms of being able to say why something is important. But a great number of things (statement vague on purpose) people have strong opinions about are not really important.
  • MEMORYC_RRUPTED 4y ago
    Totally agreed. I just decided for my own sanity that some things just aren't worth arguing about. Obviously I have opinions on my tools, but I'm not going to force my preferences on others, or spend energy endlessly debating those preferences. Work is enough mental load as is. In my experience, strong opinions about details tend to derail conversations, drain energy out of a group and just make things more difficult than they need to be. At work they use a lot of tools that have better alternatives, or alternatives that I prefer, but I choose to work with what I have and just get shit done.
    • tluyben2 4y ago
      > I just decided for my own sanity that some things just aren't worth arguing about. Yep, I was raised to question and then argue everything with passion. It’s a waste of time. Mostly people will say they agree just to make you stop wasting time; they won’t be convinced (even if you are right). I want all that wasted time back now that I’m older. I don’t need people to agree with me on everything, or actually hardly anything. And when it’s worth going to battle, you can in those rare cases.
      • alocasia-1 4y ago
        I'm not a parent but that sounds like parenting on hard mode. And I couldn't agree more - because I don't argue over every little thing, I feel like my opinions are more respected and heard when I do. (Or maybe that's just a projection of how I respond to others.)
  • Octabrain 4y ago
    I totally get what you say and respect it but I can also understand what the author means by saying that. Perhaps he did it in a very radical/too opinionated manner. Let me explain: When I am interviewing someone, I also like to ask about opinions on tooling they like/use. For example, the person I am interviewing has on his/her CV that has plenty of experience with Terraform (or I can infer it from the work experience section). One question I would ask is: What do you find good and bad about it? This helps me to get a clue about the reasoning process of the person (e.g "This person uses this tool blindly because is the mainstream thing to do" or "that decision came from a more or less rational analysis and has made the exercise of considering the flaws"). I value this because personally, I want people that can understand the consequences of a technical decision, not fanboys that learnt how to use a hammer at some point and never asked themselves if a hammer is the right thing to use (or even if they are using it right).
    • FieryTransition 4y ago
      I think you are correct in the approach to see if the individual themselves, on a case by case basis, can give well thought out reasons for their choices. But there can be a lot of fatigue in software process and tool selection, because it can be so opinionated and change from year to year quickly. I think it's the lack of good scientific studies of processes, and the immense difficulty of constructing such a study, which often leads "the best way" of doing something, to be based on personal opinions and sometimes, whatever is popular in the community at the moment. Sometimes I think that the quality of a product, really only depends on the quality of the individuals making it, tools are just a means to achieve the goal, as they can be made malable. But I digress, it's not so simple.
  • watwut 4y ago
    I can confirm. I found out that people who have "violently" strong opinions on how one tool is much worst are the ones who ... did not actually tried the other tool. In our company, people who never worked with Eclipse need to pick on it constantly, I dont know why. People who actually switched from one to another (some forever some for at some time) are waaaay calmer in their opinions.
  • mewpmewp2 4y ago
    On the other hand, with many things which I had initial frustrations about and I always assumed it's because of something I don't know and certainly there must be a reason why it's popular so I didn't want to express opinions about it and let it go, because I didn't want to seem like an ignorant person ranting about something they don't know how to use, I have developed stronger and more hateful opinions about now that I have years of experience and confidence. And then I think many who use those tools have this Stockholm syndrome type of thing happening where they try to justify why something is bad.
  • throwbadubadu 4y ago
    I think you misinterpret that: your stance is clearly having an opinion about that matter. The author is worried if you just shrug and cannot give any opinion or reasoning (which can be "this is unimportant vs the grand scheme so I dont care much about that here, but xyz more") and I would agree there.
  • marginalia_nu 4y ago
    Yeah. While there are tools and design approaches I disagree with, I do think that for the most part most stuff kind of works, and the differences aren't actually that great between good-enough and optimal. Worrying too much about these things is the sort of majoring-in-the-minors I expect from inexperienced developers. I'm much more worried about building something interesting than building something with interesting technology.
  • deleted 4y ago
    [deleted]
  • now__what 4y ago
    I interpreted this as the author saying that a senior dev will have "found an issue with something [they] love, or a useful aspect in something [they] hate..." "in a myriad of ways." I.e. I think the author agrees with you.
• black_13 4y ago
  [dead]
• manuelabeledo 4y ago
  This hits so close home, I need to know if the author is a former colleague :) I agree especially with two points: no one asks “why” enough, and the best software is the one that does not need to be written. Both often conflate as “we wrote it because we didn’t know we shouldn’t have”. I have lost count of how many times we asked “why”, just to find out that some engineer was having such a good time writing software that she ended up creating and integrating a shittier version of a widely known tool.
• bjornsing 4y ago
  Good learnings. But there’s obviously very different jobs out there all called “software engineering”. Here we’re looking at the (perhaps most common) type where the challenge is to understand what software to build. But there are certainly other types, and the learnings there can be almost the opposite I would say.
• LisaDziuba 4y ago
  [dead]
• danielovichdk 4y ago
  I have read this post probably 30 times since it was posted. Having been a software engineer for +20 years so much good is in this piece. Thx!
• idkwhoiam 4y ago
  I hope I'm not misinterpreting the point 11. As somebody with nearly 20 years in the field I found that the least knowledgeable people will often have the strongest opinions. Later in the career they learn there are no silver bullets, everything has trade offs and become more open minded.
• RickJWagner 4y ago
  Thoroughly enjoyable. My thanks to the author.
• dgb23 4y ago
  This section: > 4. The best code is no code, or code you don’t have to maintain Relativised in the last sentence: > This is a balancing act, there are lots of reasons to grow your own, but beware of toxic “Not Invented Here” syndrome. Rubs me the wrong way. I get what he is saying here. But damn this feels outdated to me coming from web development. I work in a small web dev team, but we're constantly working hard to reduce dependencies and rather code things up ourselves. We have designed it, we know how it works, what it can do and what it can't. We have tested it, we maintain it. It is smaller and more purposeful and fits our needs well. Just keep in mind that this is a learning process. You will likely suck at writing your own libraries and tools until you made some mistakes. But the end result is code that does exactly what it needs to instead of something that is cobbled together, hard to debug, hard to change. When your code breaks you can debug the code in your head, while you are walking your dog or after you woke up from a nap. You can see it all there, you can _feel_ it. With external tools, services and libraries it's not like that. It's always a black box. And it might suddenly change its contents if you look at it funny.
  • scottLobster 4y ago
    To add onto this, I'm growing more and more skeptical of auto-generation. I understand how it theoretically helps, but the issue is I now have to learn yet another proprietary language to configure the auto-generator (which I then forget because it doesn't get touched often), and when something goes wrong we can't just fix the type and move on, we have to reregenerate the whole module, often with flaky eclipse plugins that require their own arduous "get it working" procedure. Yes typing mundane things manually is a bore and subject to human error, but that's what code reviews and testing are supposed to be for. It's possible my company's just doing it wrong, but I've definitely had the experience where by the time I got the auto-generator doing what I wanted I could have just written the service/classes myself without piling on extra arcane technical knowledge that I use maybe three times a year.
    • dgb23 4y ago
      Very good general point. But I would add the caveat that generating code in a data driven way from a standardized format is fine. You change the data and re-generate the code, fix the calling code if need be. Also I think it depends a bit on the language and what exactly you generate. If you generate concrete types (or classes) then that might lead to more fixing and refactoring down the line. If you generate data it's different, because you are going to have a general interpreter for said data that doesn't care about its concrete shape.
• javier_e06 4y ago
  Check, check, check, yep, all the points are well taken. There is an OCD critter inside every developer trying to break free. We, developers, are stuck withing a rock (hardware) and a hard place (business). In my years coding (mostly C) I started paying less attention to code and more attention to people, their endeavors and motivations. It's the whole package. I must say.
• vb-8448 4y ago
  > 19. Interviews are almost worthless for telling how good of a team member someone will be I definitely agree with this statement, but I would add `but at least allow you to discard who is definitely not good`.
• slively 4y ago
  Great write up! After 13 years I find myself reflect on exactly the same points.
• emrah 4y ago
  Kudos for the caveat that all advice is contextual
• revskill 4y ago
  To me, it's simply: It's easier, simpler 100x to manage 10 small services, than a service with 10 functionalities. Main reason is, i can easily swap out, replace any small service with better one. With big service, it's impossible ! So it leads to next lesson: Learn how to compose things, or, thinking in higher level: Thinking in composition.
  • creatorbytes 4y ago
    This sounds like a microservice vs monolith statement in disguise. Respectfully I disagree, maybe with more context I’d be on a similar boat. The communication overhead is a real challenge to be reckoned with. I don’t think the mere fact something has 10 functions in one service makes it better or worse than breaking those out into their own services (not even getting into at what level do you break them down? Since most all code is a composition of functions) Personally I go monolith first, then if and only if there’s a function of the monolith that needs to scale separately from the rest of its parts, then I’ll consider making it its own service (and this has to be a pretty large extreme to take on this burden) Too many times I’ve been burnt by attempts at micro services, which seem to stagnate faster than monoliths at some companies. I also think there’s a higher degree of documentation each new service made, vs keeping it an endpoint in a monolith. But I digress
    • Izkata 4y ago
      There's an in-between point that I think is more common than good microservices, that I think you're describing, that I've seen called a "distributed monolith". Basically what happens when the microservices are too intertwined to be independently replaceable as GP suggests.
  • quelsolaar 4y ago
    Dividing your work up in to modules is sound advice. What blows my mind as a non web developer, is that when people talk about micro services they connect these modules not using a function call, but as a HTTPS request over a network to a different machine!! The orders of magnitude of latency / performance / hardware / energy / bandwidth wasted establishing a connection to a remote machine using a text based protocol, vs a native C API call is mind boggling to me.
• GuB-42 4y ago
  > Your data is the most important part of your system This is true in pure code as well. In coding, I believe there is a hierarchy, from most important to least important: data structures, algorithms, documentation/comments (not an original idea) That's because if you change your data structures, your algorithms and documentation will break, you can change the algorithms while keeping your data structures, but it will break documentation, and changing the documentation will affect neither the algorithms nor data structures. So spend the most effort getting your data structures right, then the algorithms, then your documentation. On a higher level, generally, data is useful by itself, code is only useful if it has good data to process, and documentation is only useful if it documents working code. Same idea.
  • flandish 4y ago
    I slightly disagree on priority. IMHO documentation comes first and that includes design (data structure and algo) decisions as well as managed expectations. We all want to code. But the fact is - if we want to code correctly we need to write down and manage expectations with both our customers and ourselves. (IE: “self documenting” code is one thing but stuff like “date display format” needs to be somewhere other than in a SimpleDateFormat line and if the customer/design team pivots, docs need updating first to drive the coverage in gaps.)
    • nailer 4y ago
      > if we want to code correctly we need to write down and manage expectations with both our customers and ourselves. Sure, the expectations come from code - types `Record<string, Banana>`, variable names `bananasByID`, etc. rather than some non-machine readable format. > date display format” needs to be somewhere other than in a SimpleDateFormat line The documentation I would have for this (for, say Swift/Kotlin/TS devs consuming the date display format) is The date display format is taken from the Java SimpleDateFormat using "EEE, d MMM yyyy HH:mm:ss Z", see https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html
      • flandish 4y ago
• yodsanklai 4y ago
  I have the feeling that code is becoming less and less important. In my day to day job as a SWE, coding is the easy part. There are tons of other things to do besides coding, service maintenance, discussing priorities and trade-off, helping users, fixing perf issues, code review, oncalls, tweaking configurations, understanding poorly-documented API and other systems. Maybe I'm getting old, but it seems there are more and more things to know. Sometimes it's overwhelming and the constant context switching is killing me.
  • Swizec 4y ago
    A master painter can paint anything. Deciding what to paint is where they find the challenge and the fun. First you focus on technique. Then you focus on the what.
    • grugagag 4y ago
      And sometimes you’re no master painter and don’t want to be one, you instead focus on the what and figure out the how by trying things out. You eventually learn tehnique along the way…
  • at-fates-hands 4y ago
    Same here. First few years of being a SWE I had all the romantic notions of working late in some dimly lit office with a packed war room of developers, slamming Red Bulls at 3am while you're all trying to figure out some bizarre bug that keeps crashing your web app. I had a lot of those late night sessions and major releases that you go home at 6am and are expected to be back in the office by lunch. Lately, its the same thing for me. Very little coding and actually building stuff. Its mentoring, meetings, fixing broken API endpoints or bug fixes that have lingered through multiple releases and keep getting shelved. I'm not sure if I've just lost my passion for coding, but it doesn't feel like I do much coding any more at all.
  • ip26 4y ago
    Code is just as important as ever, but a two star general doesn’t carry a rifle either.
• fatneckbeard 4y ago
  I like the Sharks not Dinosaurs thing. i keep see people saying "the FAA system was so old"... being old wasn't the problem, lack of maintenance is the problem. We have roads that are old, bridges that are old, buildings that are old, planes that are old, ships that are old, that still do extremely well. Rewriting COBOL in Javascript is not going to make a system more reliable. Making a system reliable is what makes it more reliable.
  • nanidin 4y ago
    Rewriting COBOL in javascript would make the codebase accessible to a larger pool of potential engineers who are also more likely to be up-to-date on best practices (as opposed to an engineer that has stagnated in COBOL for 30 years.) I'm not sure a rewrite is warranted, but a system isn't maintainable if there aren't enough people trained in the particular language / tech stack.
    • verinus 4y ago
      oh please no JavaScript- it is awful enough in the frontend, but that train seems to have left the station, but in the backend we have much more powerful languages and ecosystems.
    • nlitened 4y ago
      I think conditional probability of a Javascript programmer knowing best engineering practices is so much lower than that of a COBOL programmer, due to large numbers of unqualified Javascript programmers, and much higher average experience of COBOL programmers.
• neilv 4y ago
  Sometimes a pattern of an individual's learning beliefs about X ends up something like this path over time: 1. X? I don't know anything about X. 2. X is TRUE. 3. X is FALSE!!! (How silly to think it was TRUE! I'm on a higher plane of existence now!) 4. X is generally TRUE, but with caveats Y and Z. 5. X seems less relevant than P, Q, and R. 6. Better understanding of P, R, T, and V. But Q doesn't seem as important as it used to. At each step of understanding evolution, someone at an earlier step of belief evolution probably seems less enlightened. And someone at a later step, along the same path, might also seem less enlightened. (Unless you have an opportunity to understand their thinking, and choose to take it, and are able to understand it.)
• agentultra 4y ago
  Nice post! As a software dev of more than twenty years myself I nodded along with most of this list. I disagree about the value of opinions. They’re generally bad, often wrong, and don’t solve anything. Have them, sure, but keep them to yourself unless asked. We like to think our opinions are reasonable, well researched, and unbiased but nothing is further from the truth. Be open to changing your mind, let evidence and results guide you, always be open to learning new things! Opinions change with what you know so don’t hold on to them. For me the biggest difference between a senior engineer and a junior engineer is experience. The former knows enough about the state of the art in their area of the field that they can train other people in what they know. Those people that they train go on to become senior engineers themselves. One thing I’d add: if you’re a software developer, think about your principles. What maxims and rules guide your thinking? What do you value? I encourage writing those down and re-writing it every few years to see what has changed. Maybe one day you’ll be writing a list like this.
  • mewpmewp2 4y ago
    If you keep your opinions to yourself, there's no one to challenge them and so your opinions won't improve.
    • sibit 4y ago
      I somewhat disagree. I think you can challenge yourself. I'm typically the type of person who keeps my opinions to myself unless asked and when I disagree with someone about how to do/build something I'll do it myself on my own time. Sometimes I'm right and sometimes I'm wrong. As much as it sucks to realize I'm wrong I do appreciate it because it means I learned something and my opinion has improved.
  • taco_emoji 4y ago
    IMO it has a lot to do with the how well the person is able to pick their battles. Like, IMO it's weird if you DON'T have a strong opinion about tabs vs spaces. But if you're getting into serious, protracted arguments about this, then you lack the wisdom to prioritize the decisions that really matter.
  • 4y ago
• Ensorceled 4y ago
  > We should be far more focused on avoiding 0.1x programmers than finding 10x programmers ... The 10x programmer is a silly myth. I've worked with far too many 0.1x programmers, too many 1x programmers to count and maybe a handful of 10x programmers. I always flabbergasted when people say things like "The 10x programmer is a silly myth." ... have they really, in all their years, never, ever worked with a superstar? I worked with a guy who wrote the framework of a medical imaging system almost entirely by himself; hundreds of thousands of lines of FDA design systems quality code complete with tests that formed the backend of a successful product that was used on almost every MRI and CT scanner for years all while mentoring developers all around him.
  • thorin 4y ago
    I'm never going to be Linus Torvals or John Carmack, so does that make me a 0.001x programmer or them a 1000000x programmer or an ∞x programmer?
    • Ensorceled 4y ago
      Nah, it makes them a 100x. It's a bell curve and it's ok to be near the middle.
  • pookha 4y ago
    From my experience a "superstar" programmer is either somebody with Bi-Polar (works 40 straight hours) or a scam artist. Seen that playout now many,many times. A bi-polar worker can handle insane levels of work. it's just virtually impossible to keep up with them. Family member was a bi-polar canadaian air force pilot, physicist, and clinical pathologist that graduated from McGill and software developer (punch cards all the way through to Ruby). Nobody in his profession(s) could keep up with him...The other type of superstar is the bullshit artist. They slink away and start churning out unmaintainable garbage code that management loves. Than they'll disappear and the people that get left holding the bag are ".1x" programmers...I've seen those two scenarios play out a handful of times.
  • m3kw9 4y ago
    Worrying about being a 10x eng or not is like asking yourself if you are Einstein level smart. If you are not you are not. Just keep improving is all you can do, not enough people is gonna think you are 10x when you do become one, except in your imagination
• sophacles 4y ago
  Sharks also evolve. There were sharks 400M years ago, but they weren't the sharks of today. Some core banking app written in the 70s and still running today on a mainframe that requires software and hardware emulation of a 1970s mainframe is probably a dinosaur. Something like unix that sprang up in the 70s on the same types of mainframes and has evolved and changed a lot over time but still kept a lot of core conceptual DNA is probably a shark. Others I can think of off the top of my head: vi[1], emacs, C, ethernet, smtp, ethernet, excel, rs-232[2], FTP[3] There's probably plenty of others too. [1] in the form of neovim and vim in particular, but also nvi, busybox vi, and probably others. [2] i just got a box from dell that has only one non-network way to interface with it: serial over usb. I had to remember how to set up my line parameters etc. Fun fact about xterm, etc: many of them allow you to do `xterm -l /dev/ttyUSB0 115200` way easier than dealing with picocom or whatever [3] another fun fact, FTP is older than IP.
• bruce511 4y ago
  A fantastic list. And frankly the bit about context should be thing number 0. Context matters throughout everything you do in a system. So many "tech wars" come down to "you are both right in a different context." Holding a dogmatic view that "we should always do X" is usually detrimental (for some values of X). I like people to have opinions, and to make suggestions, but I tend to take more seriously those who can discuss the downsides as well as the upsides. For example, a junior I have tells me we need to switch to tool X. He lists 10 benefits of doing so. It's obvious. We're morons for not having done it already. Clearly we're incompetent pointy-haired managers getting in the way of real programmers. I ask him to argue the opposing point of view - why we _shouldn't_ change. Sometimes the quick answer is "there is no reason". But what I'm looking for is an acknowledgement of the impact of the change. The costs of retraining staff. The existance of existing code. The pushback from others. Etc Only by understanding both sides can something be recommended. I see juniors have this issue more than seniors. Seniors tend to understand that change causes ripples, and there are positives and negatives to everything. Change is necessary. But jumping on every new thing can be disastrous. Clearly my point works in my context, it may be different in yours.
• ilrwbwrkhv 4y ago
  There is this myth that there are no 10x engineers. This is categorically false. I was a 10x engineer when I was employed. I could do in a day what would take people weeks. It's an amalgamation of knowing the system, knowing how to try out ideas in isolation, knowing the editor well, a desire to build things fast and touch as few things as possible, aiming for simplicity and holding the big picture in the head. So I think this myth is propagated by those who aren't 10x engineers and just want to give up before getting there.
  • qup 4y ago
    Maybe you worked with .1x programmers.
  • c-smile 4y ago
    Well, yes and no. In my area of responsibility and expertise I (as anyone else) can do stuff 10x times better and faster. I know patterns and a set of solutions that help me to do that. But outside of that area I can be that <1x guy. Probably not 0.1x though, because of knowledge of meta-patterns common to wide spectrum of system designs, but still far from ideal ... TL;DR: Козьма Прутков: (ru) Каждый человек необходимо приносит пользу, будучи употреблен на своем месте. Kozma Prutkoff: Each person necessarily benefits by being used in his place.
    • Jensson 4y ago
      > In my area of responsibility and expertise I (as anyone else) can do stuff 10x times better and faster. I know patterns and a set of solutions that help me to do that. Can you do it 10x better/faster than other people who are also experts in that area? If not then you aren't 10x. A reasonable bar for 10x is that you should be much more effective than your peers in any codebase, even codebases they have spent years in. If that doesn't apply to you then you are just an average expert. Edit: The best programmers takes the bus factor from 0 to 1, that makes them invaluable to many businesses. A programmer who can only do well using his own code, or who writes code that others can't work with, isn't very good at all.
      • 4y ago
• sn41 4y ago
  The point about innovation really struck a chord with me. I think most people really hate fundamental change which makes life more difficult. However, users do like convenience: if you make something that is quite onerous to do, but the new method proposed is much simpler, has fewer physical steps to perform etc., they do tend to adopt it. Which makes me wonder about the whole OTP thing...
• kuharich 4y ago
  Past comments: https://news.ycombinator.com/item?id=28797485 https://news.ycombinator.com/item?id=28797485
• mianos 4y ago
  I think the less code the better is the aim but it is harder. This does not mean grab some massive framework, like Django, where you can write 10 lines and you have a whole application. It means taking a the time and care to keep things as small as possible from top to bottom. It reminds me of the quote "I have made this longer than usual because I have not had time to make it shorter. " https://quoteinvestigator.com/2012/04/28/shorter-letter/ https://quoteinvestigator.com/2012/04/28/shorter-letter/ It is hard to make things simpler. It takes longer to code and, in the end it looks like you have produced less code. This is where the 10X developers come from.
• andai 4y ago
  Re: #20: Always strive to build a smaller system. There's a quote I love I'll repurpose here: Forgive me this long program; I hadn't the time to make it short.
• jhatemyjob 4y ago
  Skimmed the article, saw the author quoted Bjarne Stroustrup, closed the tab.
  • luigi23 4y ago
    dare to elaborate on that?
    • jhatemyjob 4y ago
      He's a charlatan.
• reledi 4y ago
  Love the list just a shame to see the 10x myth. 10xers really do exist but it's hard to think about when framing it simply as 10x programmers. These are people who see two levels of hierarchy requesting something for months and then builds a prototype over the weekend that solves 80% of the problem. Who sees two teams arguing for days back and forth and gets them together to make a decision with them and moves on. Who sees the hours wasted every day on bad tooling and bloat and makes the bold decision to cull and simplify. Who sees a product team losing a quarter building the wrong thing and is not afraid to shut it down with the boss. They know how to hire A players and raise the bar. They know when to hire. They know when to let people go. They are not 10xers relative to 0.1xers, these are everyday 1xer situations. They consistently have multiple magnitudes of impact. That's not easy. For most of us that happens a lot less.
  • deleted 4y ago
    [deleted]
• bcrosby95 4y ago
  > Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software..... You need to explore other languages, libraries, and paradigms. Funny. I've used a wide range of things in my career and if anything, it's made me less opinionated, not more. There's something that sucks about everything, and usually the part that sucks is slightly different, so... why should I be so opinionated about what I'm using? It all sucks in slightly different ways anyways.
  • comfydragon 4y ago
    The way I interpreted that point is basically "if you don't think the tool/language/library you're using sucks in some way, you're not using it enough". As in, "opinionated" here doesn't mean "you should use this, everything else sucks" (which is what opinionated usually means in software contexts), it means you have opinions about these things that are founded in experience, not impressions. In that light, you ARE opinionated.
    • danwee 4y ago
      For instance, I am opinionated... but I keep my opinions to my own (e.g., personal projects). When working with others I'm less likely to be like that because, well, everything is more subjective than it seems. From my point of view, there is nothing more junior than being fixated with the idea that tool X is the only tool for job Y.
  • Cthulhu_ 4y ago
    But knowing how different things suck is what makes you opinionated; not knowing or caring why something sucks is being indifferent.
• wirthjason 4y ago
  On the sharks vs dinosaurs topic, I’m curious how this applies to languages and if C++ is a shark or dinosaur. Of all the languages that seems to be one on people talk about as being on the edge of extinction (Rust, Carbon, Cpp2, etc.) but keeps on going.
• ykovalenko 4y ago
  What a great post! I could relate to most of the points. It is for sure one of the best articles I’ve read which covers this particular topic. Thanks Justin for putting in the time and effort for sharing your thoughts.
• komali2 4y ago
  > If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system I'm feeling like this is my next major skillset to improve. I've been building software for just over 6 years now and I can crank out a mean fullstack webapp in either JS/TS or Python, I can deploy it on a few various cloud infrastructure setups I've used (or just a VPS really), I can plug it into various databases or database services-as-apis, to the point that whatever problem a client could bring to me, I'm pretty confident I could answer with "yeah we can build that," and then do so. But what I'm discovering is that there's a lot of things already built, and that if I can learn to simply deploy / integrate / zip together the right already-built things, the possibilities for the services and solutions I can offer on a timely basis increase dramatically. The problem is I'm completely overwhelmed by the equations necessary. A few concrete examples: 1. A local chain of ~20 hot pot restaurants approached me and asked if I could build a membership loyalty app (會員卡 APP), with features that allowed for tracking membership loyalty across the various brands and restaurants they have to promote cross-business sales. Sure, I could build that in react native, customer accounts, simple phone authentication, plug into the taiwanese version of twilio, plug into, i dunno, airtable, whatever db as a service I want. But wait, they also want to eventually display the menu, have an admin app to manage menu items, ok now we're talking ecommerce / CMS. I mean I could build that out from scratch but shouldn't I instead try to plug in a headless ecommerce or CMS like medusajs or contentful? Well then I gotta deploy those, should I just get a VPS and throw them all on there? And what about the original member loyalty thing? Oh there's plugins for that, they just cost 90$/month, well fuck at this point maybe I should just buy a whitelabel restaurant POS system, then the only time I need to spend is in setup, then again, those are also expensive... but so is my time spent engineering whatever parts of this I need to do from scratch. 2. The local visa office is interested in a submission and display portal for immigrant stories here, something simple. They were considering submit.as as it's basically the exact featureset they need, but the pricing is a little... much. Shit, an anonymous submission CMS with admin publish features? How hard could that be? That's basically just a coding bootcamp project... right? Eh, imo it would probably take me a solid week or more to do something like that from scratch, or at least do it well, maybe I'm slow, but I decided instead to see if another platform could support that. Took me a weird amount of time looking at the bajillion CMS / blog implementations before I realized Drupal can do that pretty easily, but the hilarious thing is I only know about drupal as of a few months ago when I was looking into various CMS for the restaurant app thing. Basically I went 6 years in my career taking designs from designers / executives and implementing them as new fresh codebases or in existing codebases. I've never really had the opportunity or projects where "wait, isn't this just a CMS?" or "can't we get these features by deploying an ERP and using the API it auto-generates?" were potential routes we could go down. Now that I'm touching that world, every time I start poking around, I'm totally overwhelmed. I gotta admit I find it much more fun to be implementing custom SaaS or whatever else from scratch, I really haven't enjoyed spending hours comparing hosting prices and license fees vs my estimation for how much time it will take me to plug x open source ecommerce UI into z open source ERP on top of y VPS service (and do the server requirements match??). Mostly I just wish I was better at doing the latter because well for one it'll let me pick up more gigs for my team cause we can apply ready-made solutions to a lot of people with the same problems, but also two because it's fuckin cool how much work people have put into a lot of these open source solutions and I'd love to use and contribute to them more (I've already had some PRs accepted on missing / incorrect deployment / installation docs, it feels nice).
• albertopv 4y ago
  14y of experience, good 10x devs do exists, but they are extremely rare. Everyone opinion is important, I learned there's not enough different point of views, edge cases missed...
• rrgok 4y ago
  Overall nice post. But the point 5, irks me the wrong way. Every time I read something along the lines of that paragraphs, something inside of me dies. At expense of being downvoted to hell. I'm gonna say it in caps to emphasize, not to shout: IT IS NOT THE RESPONSIBILITY NOR THE JOB OF THE SOFTWARE ENGINEER TO DELIVER OR PRODUCE VALUE. This doesn't apply to all Software Engineers (like the one who sells the product is also the Software Engineer, or writing open source libs to other developers, some freelancer,...). It makes me sad to see how many Software Engineer are brainwashed to put up with the stress of producing value. When people like PG, DDH or you name another CEO/Cofounder, say: ultimately we should produce value. They are not talking as a Software Engineer, they are talking as people who owns and sell products/service, who happen to be the Software Engineer of the product/service. I, as employee Software Engineer who produce software that other people use and a sell, must not be concerned about the value of the product/service. My only concern is to design and implement what they ask for. Whether what they ask for as any value, it is not my responsibility. It is their money, they should find value in what they asking from me. Why? Ask yourself if you are ultimately participating or have any say in the pricing of the product/service? Or do I sell the product/service myself? If you answered to No to both, then it is not your job to produce value. I hope in the coming years we reduce the stress we put on Software Engineer. In the last years, I keep seeing this trend of making Software Engineer to everything.
  • hbrn 4y ago
    > IT IS NOT THE RESPONSIBILITY NOR THE JOB OF THE SOFTWARE ENGINEER TO DELIVER OR PRODUCE VALUE. Says who? Is there a law that forbids it? If companies where SEs are focusing on value are more successful, then naturally it becomes SE responsibility. > My only concern is to design and implement what they ask for What they ask for changes over time. The hardest part of SE is not building first version of the software, it's evolving it. If you don't understand where the value is coming from, you will always make wrong predictions. Given freedom, you will always choose to focus on things that matter to you (performance, scalability, fancy tech, etc) instead of things that matter for the business (growth, UX, features).
    • rrgok 4y ago
• jasmer 4y ago
  Love it! Is there a way we can accelerate this learning?
• basicallydan 4y ago
  This is a very well written article, and thank you for the advice. Lots that resonates here.
• onion2k 4y ago
  There's a lot to like here, but, as with almost all 'advice' lists, the author makes the mistake of believing their own hype. They're effectively saying "I am a good developer, I do these things, therefore to be a good developer you should also do these things." It ignores the possibility that there are good developers who don't do those things. An example is the advice that "Software engineers should write regularly." Why? Can't you be an awesome dev if you don't write? You definitely can, because I've met hundreds of great devs who've never written anything that you'd call 'writing'. Devs who enjoy writing, and get something from writing, should absolutely write things. If you're a dev who doesn't enjoy writing then you probably shouldn't force yourself to do it just because someone said it's what devs should do. Find a different outlet that gives you the same thing other people get from writing.
  • haspok 4y ago
    One "easy" way of "writing" is to answer support emails / calls. It is almost the same as teaching stuff, only with a more relaxed timeline. I am currently supporting a system (and have been supporting other such systems in the past) about which I know very little. So each time a support request comes in I have to dig, understand, formulate an answer, scrap it, dig again deeper, ask around, etc. In the end I don't even care if this takes a lot of time, I learn so much in the process that it is absolutely worth it. I would not be happy doing it 100% though, because writing code is really on a different level, but I find that these two complement each other very well.
  • atoav 4y ago
    Corellation is indeed not causation and humans are good at finding patterns where there are none. He might also drink a strawberry milkshake each monday, or pray to the arcane, binary gods before going to work. However it is okay if someone says: "Writing helped me as a developer. It might be different for you." Hopping that easily from "works for me" to "must work for everybody else" without a second thought is indeed not reassuring coming from a software engineer where "works for me" is not enough.
  • munchbunny 4y ago
    I’d definitely agree that “software engineers should publish writing regularly” might be off the mark, but “software engineers should be able to write well” is pretty uncontroversial. And being able to write well comes from focused practice, however you get that practice.
• nathias 4y ago
  very good points, I agree with the sentiment, but the best code is not no code, it's negative code
• danwee 4y 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 On the contrary. The more senior I get, the weaker my initial assumptions about everything becomes. The more I know, the less I know (so the less I push my ideas into other's people's minds)
• deleted 4y ago
  [deleted]
  • deleted 4y ago
    [deleted]
• CM30 4y ago
  This is one of the best pieces of advice in the article: > You learn so much as you’re building a system that you will end up iterating into a much better system than you ever could have designed in the first place. This is surprisingly a hard sell to most people. And it's one I wish I'd kept in mind for a lot of personal projects in my life. I love designing stuff up front and implementing things based on that, but often that's led to sticking with ideas that didn't actually pan out the way I expected them to, especially when it comes to game design/development. A lot of the time, a good level or game or boss fight or whatever is completely different to what you initially imagined it would be, and you should be willing to change direction to fit the bill. > Sometimes you have to stop sharpening the saw, and just start cutting shit Also this one for much the same reason. Overplanning for things is a curse, especially when said plan hasn't quite come into contact with reality.
  • BerislavLopac 4y ago
    This is called the second-system effect [0], and has been described by Fred Brooks in his book The Mythical Man-Month, published in 1975. [0] https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month
  • MrGilbert 4y ago
    > And it's one I wish I'd kept in mind for a lot of personal projects in my life. It's one thing I'm currently doing, and I'm quite happy about it: I always wanted to have a project that could "grow" with me, but never had an idea. Turns out I already have that: My personal website is running on an engine I wrote myself, basically just turning a directory into a website (like Directory Listing from Apache, but more powerful). I'm currently in the process of refactoring it. Eventually, I'd like to host it on GitHub. :)
  • agumonkey 4y ago
    It should be taught how to "size" your planning / iterating balance. Few years ago I made a tiny vue app (to learn that lib) and every time I though adding a feature would go one way, it went another, and made me see things I didn't perceive about the app structure. At first it felt frustrating but if you size features on the smaller side (~agile spirit) and change your spirit it becomes a new kind of pleasurable skill in itself. It also impacts how you write code, because you anticipate a bit the potential refactorings now. So you tend to become very frugal and efficient in how you code and how you abstract. Which another pleasurable skill. Something no moonshot side project ever taught me.
• CM30 4y ago
  As for the whole 10x programmer debacle... well it all depends really. Are there people who are better at programming in general? Sure. But there are also plenty of people who just seem like that because the company they work for demands less than their full expertise. The same dev who's a '1x dev' at Google or Facebook or Apple might be a '10x dev' at a small web development agency, and a '100x dev' at a business which doesn't specialise in software engineering at all. And the same goes in reverse. Point is, the environment and how well your practices gel with those of the team/company have a huge effect on how productive you are, as do numerous other factors. It's basically the whole 'nature vs nurture' thing really, and both aspects play a role in how skilled a dev anyone is.