20 ms·

Things they didn’t teach you about software engineering

• zer00eyz 4y ago
  One thing is missing from this list. No one ever gets promoted for removing features. Any code base that has had a few birthdays has stuff that needs to be removed and might not ever get removed.
  • jsmeaton 4y ago
    This can be a cultural thing but it needs to permeate down from the very top of engineering. Celebrate and promote cleanups. Track metrics you want to improve. Create burn down tickets that’ll help others to incrementally improve some system. I’ve only seen this work in one company I’ve worked for and will carry those lessons with me.
• revskill 4y ago
  Not quite. You really need to write things from scratch to reduce repitition. Things like custom DSL, code generation,... is not there for you in first place. Domain understanding is just understanding, it's not related to HOW you do it effectively.
• invalidname 4y ago
  I like this list. It's also missing "debugging". That's a skill that they don't emphasize in college because they can't test it and it's hard to teach. But there are ways to teach it and techniques. There are some books on the subject: https://www.amazon.com/dp/1484290410/ https://www.amazon.com/dp/1484290410/ https://www.whyprogramsfail.com/ https://www.whyprogramsfail.com/ That can mitigate that a bit.
  • orderedtree 4y ago
    Why can't debugging be tested?
    • gregmac 4y ago
      I can think of a couple challenges. Let's say you're debugging "the website won't load." Often debugging is a hunch, and quickly branches. One person will go down the path of trying the same site from another PC. Another will try a different site from the same browser/PC. Another will try to ping the server. If you're running this live you're always going to have the chance where someone's hunch or first try basically pinpoints the problem and eliminates a dozen checks from their consideration. If you're looking for things like "did they check DNS? Did they try another site?" but they skipped that and immediately figured out apache wasn't running, do they lose points? Or do they get 100% for their lucky (and/or experienced) guess? If you do it on paper, the major problem is basically infinite branching for every step and possible result. How do you mark that? What's the minimum you need to do to get 100%? I think it's also unfair, because even as a seasoned vet I've been deep in troubleshooting to the point of (for example) greping source of nginx for a specific error message -- which I'd never have even thought of two steps earlier. I do t expect anything that complex on a school test of course, but the point is the result of each step is often the only way to even think of the next.
      • atoav 4y ago
        Sure testing a beginner is hard here. But testing someone who learned how to debug means testing their knowledge of the moving parts of the system they are debugging. And this can be explained by the person being tested. E.g. "I am going to ping an IP on the outside first, to see if ICMP message reaches the outside server. If yes I will check if the DNS server responds, if no we check the physical connection." That would be an ideal answer, judging less ideal answers fairly is certainly a challenge, but not impossible.
        • no1lives4ever 4y ago
          And what if the firewall blocks icmp? What if the dns server is internal to the network and is returning a stale ip? There are way too paths down this rabbit hole.
          • 4y ago
  • djmips 4y ago
    Debugging is always overlooked. Even in blog posts.
  • yamasanama 4y ago
    Most non-trivial programming homework assignments in college require debugging and a good school will provide guidance of how to do this. One thing I do in job interviews is to have the candidate debug an issue (that they usually caused themselves and that I let them purposefully run into). Quite the eye opener of how they approach bugs.
    • invalidname 4y ago
      You would need to debug but can you tell if a person just printed to the console or used advanced tooling? Can you tell how long they wasted on the debugging aspect? Nope. That's the problem. These are soft skills that are hard to teach but much harder to test.
      • yamasanama 4y ago
        Yes, I can tell, because in the interview situation I'm sitting next to them. And print statements are sometimes the superior choice. This ties into my other comment that these things can be heavily subjective. As long as it gets the job done, I prefer print statements used by somebody who uses them as a sharp knife to gain understanding of what's going on over somebody just clicking buttons in a fancy UI but has no clue. (And vice versa, obviously.)
        • invalidname 4y ago
          I'm talking about universities not interviews. Print debugging is sometimes useful but sometimes indicate the person doesn't know about tracepoints/logpoints.
  • josephg 4y ago
    I also find it odd that nobody is ever taught to read code. We spend a lot of time writing code, but how many programs does the average CS grad read by the time they graduate? Imagine going to school to learn how to write, but in the course nobody ever reads anyone else's work. And in fact, most people (including the professors) never read any books. For some reason, thats the status quo in software. In industry, learning to read other people's code is one of the most valuable skills there is. There's plenty of times I've run into a showstopper bug in some opensource library we depended on, or needed another feature that was missing. If you can't read code, how can you fix the problem? Hope there's another library out there which solves your problem better? Implement some complex workaround? But if you can read - well, you can just dive into your dependency, debug the issue there and file a PR. (And if you like, use a fork with the fix until its merged upstream).
    • jdougan 4y ago
      You might find this interesting https://www.dreamsongs.com/MFASoftware.html https://www.dreamsongs.com/MFASoftware.html:
  • sureglymop 4y ago
    I find debugging hard when it comes to web development. How can I debug a typescript web app when 1. It will actually be in javascript once it's transpiled and 2. It will run in the browser and not in my ide. It uses some kind of live reloading dev server that is completely different than the production build. Currently I'm building something with sveltekit and i have no idea how to debug this except logging out messages.
    • invalidname 4y ago
      The first book above has a chapter of various tools in debugging web applications. You can use the sourcemap feature to debug TS. You are missing out on a lot of amazing capabilities by avoiding the browser debugger. Did you know you can place a breakpoint that will trigger on DOM mutation?
    • hermanradtke 4y ago
      Most languages are compiled or transpired into another representation. For TypeScript, source maps can help with the debugging. The live reloading dev server is just a wrapper around your code. You should still be able to use the browsers debugger to set a breakpoint at the function you want.
    • gernb 4y ago
      I don't know what your setup is but I've had no trouble debugging typescript in the browser or on the server. In the browser I use the browser's devtools and source maps. It works. For the server I use VSCode's built in node debugger integration. Both have worked great for me.
    • flohofwoe 4y ago
      If the code is running in the browser: source maps are the answer (there's a step-debugger in the browser's devtools panel). But also: Modern Javascript is (more or less) just Typescript with the type hints removed, so even debugging the output JS code is pretty straightforward.
    • deleted 4y ago
      [deleted]
• zabzonk 4y ago
  i thought this was pretty good, the point on aesthetics in particular - how much code have i seen and thought "how could you have written something so ugly?"
  • EdwardDiego 4y ago
    At my first coding job, my CEO passed on to me his belief that code that looks ugly should be refactored asap, as the ugliness not only hides, but rather implies, bugs. He's been right quite often, as I progress through my career.
  • yodsanklai 4y ago
    Maybe because it's Friday night, you want to go home, there's one more test to fix after a long day of work and you don't have time to pull out the perfect design. Or the code is already ugly when you start touching it, your manager is assessing your performance based on features. Any time spend on refactoring is time you're no shipping features (worse, you may introduce new bugs). So you add your feature, making the code even uglier. Or of course, the person who wrote the code was not very skilled.
    • nunez 4y ago
      or you just need to ship something fast but never get time to "make it right" there isn't a lot of value in clean code beyond making it easier to maintain. it can be argued that clean code over time makes code safer by way of improved maintainability (which is true), but 99% of the time, customers won't buy software because of how clean the internals are. meaning: if a customer is willing to commit to purchasing your widget or your competitor's for $LOTSOFMONEY if a single feature is created for them, then you can bet your ass developers in both companies will author (be told to author) the shittiest version they can that works to win that customer. think about the last thing you bought that you REALLY needed. did you care that it was a generic brand that looks crappier but gets the job done? same thing. disclaimer: i am a huge believer in clean code and TDD.
• KrugerDunnings 4y ago
  There is nothing wrong with this article in trying to paint a realistic picture of what is expected of a software engineering nowadays but man am I getting tired of this one sided culture of professional responsibility. I just don't vibe with this advice anymore, like all the same with me but I'm gonna call myself something else then, you can have it.
  • edwardsdl 4y ago
    Can you elaborate on what you mean by “one sided culture of professional responsibility”?
    • KrugerDunnings 4y ago
      > Highly unlikely that you will make a meaningful difference in the world This is an example of negative self talk, stop this, the reason you are broken is because you are trying to fix something, this just leads to more anxiety. Most self-improvement content by developers for developers tends to be very negative like I can't explain it really well but to compare it to this sketch: https://www.youtube.com/watch?v=85HT4Om6JT4 https://www.youtube.com/watch?v=85HT4Om6JT4
      • HellDunkel 4y ago
        I did not perceive it as a self improvement piece that much but you are absolutely spot on: the professional responsibilities are unevenly distributed.
  • intelVISA 4y ago
    Whoever wrote this hit the enterprise koolaid a bit too much, you're meant to sip not swallow. Calling SWE "working in IT" is where it lost me.
    • eddsh1994 4y ago
      The majority of software developers are working on what is, essentially, IT both literally and in the business sense of the word.
• surfsvammel 4y ago
  Some more: The worst are when you run into code that’s been around for a long time, but obviously doesn’t work, but which have stuff built on top of it relying on it not to work. When two bugs manifest together in one symptom, the engineering approach that you have learned about breaking a problem down and testing one thing at a time, might not be enough to find the issues. All projects are chaos, learn to accept that and to navigate it. Centralising things into common classes, methods, functions, libraries, modules or services, for reusability, and for less redundancy, also increases risk, as it is now even more important that that stuff works.
  • 8note 4y ago
    Said dependencies on bugs are some of the most interesting things to document, because they're non-obvious, and hard to change
• cam0 4y ago
  I had never seen that cartoon about the "dream job" before, but it's something I've thought about so many times as I've listened to people talk about their dream job or dream employer. It always struck me as strange to dream of labor / dream of being an employee - must be a cultural thing.
  • intelVISA 4y ago
    Dream 'job' is 404 for most I'd imagine. There's always the hardcore grifters who try and signal otherwise I guess.
  • geysersam 4y ago
    On the other hand, working is what most of us spend 8 hours a day on. It makes sense to make the most of that time, and not all jobs are equally interesting/fun/rewarding.
  • quanticle 4y ago
    Programming is a "dream job" for me. I'm getting paid to do (approximately) the same stuff I would be (and am) doing on my own time, and I have entire departments whose job it is to handle the boring drudge work, like accounting, taxes, billing, client meetings, etc. etc. Sure, there are trade-offs. I have to use a language that I'm not entirely happy with, infrastructure choices I don't fully agree with, pre-existing code, and meetings that I find irrelevant, but, overall, I'm happy with the tradeoff. And besides, it's not as if you're free of those things as a freelancer.
  • randomdata 4y ago
    There is value in dreaming about your options. A dream house is another example of this. Let's face, housing is awful. The pie in the sky dream would dream of not needing housing at all, but more realistically I can also dream of a house that makes some things slightly less awful. Dreaming about that house provides me with information that I need to move towards it. More likely it is a semantic thing. I imagine everyone does something like that, but may not call it dreaming.
    • 4y ago
• HollowMan 4y ago
  After 10 years in the industry I agreee with almost every bit. Soft skills are never taught, rarely checked during interviews, but might well be themost important ones.
  • HollowMan 4y ago
    > Estimations will be asked even when you don't want to give them Actually this particular point reminds me of young-arrogant-me saying things like "I can't give you an estimate since its software, and everybody knows thats estimates are impossible, duh." to my boss. Boy was I young, and arrogant!
    • randomdata 4y ago
      When I was young I didn't want to give them because I thought they had to be accurate, and pined over being wrong, wasting hours trying to ensure I covered all my bases and basically doing the work to get there. I was quite good with accuracy, which helped feed my belief, but the effort to be accurate was monumental. Thankfully, I eventually came to realize that you can choose a random number. Nobody gives it another thought after you've answered.
      • mmcnl 4y ago
        I think it's literally what the word estimate means though. There's a reason people use the word estimate and not prediction. They want to know whether it's going to take 3 days, 3 months or 3 years.
        • deleted 4y ago
          [deleted]
        • randomdata 4y ago
          Yes, but what wasn't clear was around the margin of error. I assumed there was an expectation of being close. If I said eight hours and it took nine, close enough. But if I said eight hours and it took a year, that was once concerning, but I eventually learned that I could say eight hours for a year's worth of work and nobody would actually reflect back on it anyway. All that mattered was answering the question with something.
• theteapot 4y ago
  > My god, how many times has my Linux machine crashed with a segfault? It’s crazy. Zero times? It is crazy.
  • atoav 4y ago
    Zero times here as well. And I run ~10 servers, and use Linux as my daily driver on my laptop.
  • selivanovp 4y ago
    The last time any of my linux machines crashed with a segfault was in early 00’s. In most cases the reason was in shitty drivers for some hardware.
  • LtWorf 4y ago
    Happened to me because of nvidia video card (unused) on a work machine… changed the bios to not use it and that was it. That's out of tens of machines, over several years of running linux.
• eikenberry 4y ago
  > Domain knowledge is more important than your coding skills In the short run. In the long run the lack of coding skills will start to show and bog things down. You need both domain and design in equal amounts for the long term success of a project.
  • fullstackchris 4y ago
    Agreed. If you have a sharp grasp of most parts of the coding you'll need to do, the domain stuff is trivial (after reading a few articles and such). There is probably one small exception, and that is the horible esoteric world of SAP - esentially a bunch of made up production flows on top of more made up production flows, filled with alphabet soup that ultimately piles up to mean a whole bunch of nothing.
• mikewarot 4y ago
  Once I wrote a green-field application in Turbo Pascal for MS-DOS, did all the field editing and screen handling, help, communications, and even cooperative multi-tasking. It was amazing knowing how everything worked. I'll never experience that again. 8(
• fhd2 4y ago
  "Estimations will be asked even when you don't want to give them" I think usually it's not a matter of not "wanting" to give them. It's a matter of not wanting to take a wild guess - which is talked down if it seems too high - and then be asked to finish the work in that time frame. Time or scope, at least one of these things needs to be flexible, and stay flexible until the work is done.
  • jsmeaton 4y ago
    Estimates are not commitments. More people need to understand and accept this. You’re on the money about time and/or scope needing to be flexible. Estimates improve as you gather more information and complete parts of a project. Providing early feedback that relates to the original estimate is key! “This is more complex because of X, and will likely add Y time. Do we want to proceed?” Nothing worse than getting to the end of an original estimate and only then letting a project owner know it’s going to be twice as long.
    • philipwhiuk 4y ago
      > More people need to understand and accept this. Wishing upon a star that people are better is a terrible plan.
      • jsmeaton 4y ago
        It can be taught and there has to be general agreement. Building trust with early feedback as scope/complexity changes is crucial. Wishing is indeed a terrible plan. Teams that treat estimates as commitments are dysfunctional. Estimates are a tool for budgeting in an agile-like world, and need to be refined as progress is made.
    • wlonkly 4y ago
      One model that I picked up somewhere (but I don't remember where), which I teach to anyone willing to listen, is that there's four kinds of dates: - Estimates (I think it will take X long) - Targets (I would like to have it done by X) - Soft deadlines (with low consequences for missing) - Hard deadlines (with high, usually external, consequences for missing) and that understanding the model and using those words solves quite a bit of confusion around dates. Of course sometimes targets become soft (or even hard) deadlines because humans are messy, but being able to distinguish those things is a step in the right direction.
• quanticle 4y ago
  Rare work-life balance. In other professions, your work day ends at 18:00, and you forget about the job. Not here. You will most likely always be online and checking the code, even in the evening. If that's the case, quit immediately. I've been in this industry for over a decade (oh god, has it been that long already?) and I have never had a job where I was "always online and checking the code, even in the evening". Not even when I worked at Amazon. Yes, I've been on-call. And yes, I've been paged, but never at anything like the frequency that would imply that I'm "always online".
  • yodsanklai 4y ago
    First, there are of course many professions where you work day doesn't end at 18:00. As for our industry, I don't disagree with you but I'd be a bit more nuanced. I'm not pressured to work long hours. But I often feel that if I want to reach my goals, I need an occasional coding marathon (which I don't mind because I do like coding, like everybody else doing this job I suppose).
    • quanticle 4y ago
      Right, that's the contrast I wanted to draw. In many other professions it is routine and expected that you're available in the evenings or in your off hours to deal with urgent (potentially life-threatening) issues. Programming is not one of those. If you're routinely being called upon to actually work on code in the evening, that's neither normal or healthy. An occasional coding marathon is fine. I've done it myself, but I don't expect it of anyone else, and if it became a routine expectation (as it seems to be with the author of this post), I would consider it a major red flag.
  • Galanwe 4y ago
    > If that's the case, quit immediately If you're so uninterested by your work that thinking about it after 6pm makes you sick, why did you pick it? I've been in the industry for 15 years, coding since 25+ years, and I very often think, code, read about work or work related things at any time of the day or weekend or vacation, because I find it interesting. Why would I work in something of no interest to me?
• osigurdson 4y ago
  >> Managers like numbers, estimates, and asking for estimates with an idea written on a napkin. It's just how the real world works — a business has some monetary goal, but before committing to it, it needs to understand how much it will cost. I think everyone squirms when asked to make a prediction with too little information. If you want to see a developer squirm. ask for an estimate for how long it will take to build a given product or feature. If you want to see a PO squirm, ask for an estimate (in $) of the expected cumulative revenues for the same product or feature.
  • kimburgess 4y ago
    A lot of this stems from the accepted norm that an estimate is a single value. This loses a lot of information and when combined with other lossy estimates, this error compounds. Pair any estimate (time, cost, effort) with a confidence indicator. This will likely improve as more about the problem is known, but until then gives the ability to reason with appropriate certainty based on a set of inherently noisy priors. There’s a whole set of more formal systems such as PERT (https://en.m.wikipedia.org/wiki/Program_evaluation_and_review_technique https://en.m.wikipedia.org/wiki/Program_evaluation_and_revie...) which base off this principle. That doesn’t work for every project, but there’s often an over correction in ‘modern’ software teams where significant research, experience, and process that has been designed to avoid project chaos is completely ignored for the sake of being ‘lean’.
    • valenterry 4y ago
      Exactly. As a minimum, it should be something like "90% chance it will be between 3 and 10 weeks, 50% chance it will be between 5 and 6 weeks". Optimally we have a probability distribution. Not to forget that over time the confidence will grow and estimates become more precise.
    • kqr 4y ago
      A single value isn't the problem -- the lack of an indication of confidence is. If I say "there's a 90 % chance it's done before March 13." that's a useful and verifiable estimation, even though it's only one number.
• randomdata 4y ago
  > Meetings are there to ensure that everything is going smoothly and on schedule. Are they? At one time in my career you just let people know when something isn't going smoothly/not on schedule. A quick email (or equivalent) was more than sufficient to raise awareness. For various reasons I eventually fell into this meeting culture. I don't get it. It produces this weird state where everyone saves up what they have to say for the meetings to avoid an awkward lack of participation or "I have nothing" in the meeting, which results in a barrage of mostly useless information, all while the nuggets of gold that the meeting would benefit from regularly get missed because everyone is too overwhelmed by the information overload. And because everyone saves up what they have to say, the team seems more distant, which diminishes other beneficial outcomes that arise when everyone is regularly chatting with each other. The information lag also dramatically decreases the overall efficiency of the team, not having useful knowledge as it becomes available. > You might not like it, but the information must be shared for the system to remain efficient. The thing is, I actually like meetings. After you've recognized something isn't going smoothly, calling a meeting to formulate a plan of attack under the narrow scope of that specific problem at play can often lead to really great outcomes. But I dare say that if the meeting is there simply to find out that there is a problem, you are doing something wrong.
  • yamasanama 4y ago
    > It produces this weird state where everyone saves up what they have to say for the meetings to avoid an awkward lack of participation or "I have nothing" in the meeting This is an odd meeting culture. Just remove the requirement that everybody has to bring up something. FWIW I've never felt like that in my teams.
    • randomdata 4y ago
      I'm not sure it can be removed, fundamentally. After all, if everyone sent out their emails, so to speak, what would be left for the meeting? I mean, what are the odds of someone discovering something worthwhile to communicate to the team just seconds before the meeting starts? Any earlier and the email would have already been sent and there would be nothing left for the meeting. Maybe it happens once in a blue moon, but regularly across a wide number of people? No way. I've never attended a status meeting that was completely void of participation, so there must be withholding of information done so to pad the meeting. Not everyone may feel such pressure, but it is apparent that some – and I dare say most – do.
• yamasanama 4y ago
  Missing from this list is that lots of the mentioned concepts are highly subjective. There is no generally agreed-upon standard of what documentation is "proper". Or what "clean" code is. Or what "competence" looks like. Or what a "scalable architecture" is. Etc etc. Most of these words are bent by whomever using them to make a point (or to boost their ego, sadly). Two people could easily work side-by-side and claim about the other that that person is incompetent and defend this position here on HN with some horrible-sounding anecdotes.
• nitwit005 4y ago
  > Meetings are there to ensure that everything is going smoothly and on schedule. Hospitals are there to provide health care. But you'll sometimes hear a phrase in health that "a hospital bed built, is a bed filled" (https://en.m.wikipedia.org/wiki/Roemer%27s_law https://en.m.wikipedia.org/wiki/Roemer%27s_law). Health organizations will push patients to get extra, often unneeded, treatments if they system has extra slack. Similarly, management calendars always seem to fill. It doesn't seem to matter what the ratio of staff to management is, or what's going on at the moment.
• renox 4y ago
  One thing missed: there are two kinds of meetings, the one where nobody wrote down the points discussed==>time wasted, the rare one where someone wrote a résumé of the meeting with clear action points and made sure to send the document to everyone asking for feedback, etc. These meetings are gold (provided the discussion was about concrete actions not moonshots)
• jffhn 4y ago
  >Domain knowledge is more important than your coding skills It depends. For hiring I would focus much more on coding skills than domain knowledge. Reminds me of a company that was getting rid of the expert/developper communication bottleneck/gap by having domain people who code, and said it was much easier to teach the domain to a good developper (who should end up knowing it anyway, possibly in more details than experts themselves, due to formalizing it in actually executable code (requirements often don't even "compile")), than to teach coding to a domain expert.
• rawoke083600 4y ago
  Good list ! The one thing I would add or emphasise: Is communication skills I WISHED in addition to Calculus and CS that some form of "effective communication course" was required up to 3rd year ! Even the "basics" like how to "Respond Vs React (the emotion)" If you are a coder 90% of the time it's going to be a "social" or "team" activity. And where you find people you find people problems, egos, miscommunications, anger etc ! The amount of time you will have the debate about "how to code something the 'correct' way" will be the cornerstone of your success in a team. That 'debate' about the 'correct way' is hard since CS is such a young "engineering discipline" compared to say how to build a bridge. I can tell you this, the other coders I worked by far the best with are the coders that can communicate or that I feel 'safe enough/trust enough' to talk honestly and openly and separating yourself from your code ("you-are-not-your-code") becomes automatic with these types of pro-communication programmers. TL;DR: If you want to be an effective or standout coder: Focus HEAVILY on your communication skill.
• gernb 4y ago
  > Remote work can lead to isolation. Depending on the company and team structure, software engineers may work in solitude (not including video calls) for long periods, leading to a lack of real social interactions. Yep > Rarely you're building something you love. More often than not, it's tedious work that needs to be done You should switch jobs. The majority of my jobs were building something I love > It's hard work. You're sitting behind your computer most of the day. That's not hard. That's what I would do even if I didn't have a job.
  • the_only_law 4y ago
    > You should switch jobs. The majority of my jobs were building something I love Lmfao if they would hire me I would.
• flohofwoe 4y ago
  > Code is secondary. Business value is first. Eh, what a predictable and boring attitude :/ This advice makes sense in a company environment, but there's so many other motivations to write code than just 'business value'. And from what I've seen, focusing on 'business value' alone is the only explanation why so much software written in company settings is so user-hostile nowadays. My counter-hot-take: focusing on business value makes you a worse programmer.
  • sorokod 4y ago
    Worth stating nevertheless as the article is about a software engineer. Not a programmer, coder or hacker.
    • flohofwoe 4y ago
      And that's exactly my other gripe! :D Those are all the same, the best programmers in the world (those in the demo scene) call themselves 'coders'. Calling yourself a 'software engineer' reeks of elitism, no matter how much time you spent at university.
      • goodpoint 4y ago
        Not at all. Software engineering is very much a thing and requires a different skillset than programming.
        • flohofwoe 4y ago
          I suspect this may be a 'cultural' issue: For instance in Germany with its strong engineering tradition, nobody in their right mind would call somebody who builds software an 'engineer' (there are some google hits for "Softwareingeneur" but I bet this has a fairly recent thing and has been leaking back from English). A person who builds software is simply called a 'programmer' or 'developer' here. And I really have my doubts that there's any meaningful difference between what's called a 'software engineer' in the US and a 'programmer/developer' in Germany. Building software requires creativity, planning, experience, rationalism and problem solving abilities, all in the same person. If you don't have that, then don't call yourself a 'programmer' ;) Out of interest what are the different skillset requirements between 'software engineering' and 'programming'? Because I really can't think of any.
• tapanjk 4y ago
  > One way I have found to be effective is to focus on being productive despite the other person. I try to find solutions/alternatives that may be more effective and don't require involving the ineffective person. This above line may sound arrogant because it sort of implies that you are the smartest of the lot. For all you know, you may be the incompetent one for someone else. However, this attitude (without being a pr*ck about it) can be very useful in navigating your way through the messy reality and becoming more productive in spite of it. It will prevent (or reduce) a lot of "you should have said this before", or "I should have known this before", or "you cannot change that now", or "who wrote this code?" moments.
• fullstackchris 4y ago
  > You’ll need to work around incompetence This one I am truly struggling with, and probably will the rest of my life. Sadly it hinders the success of all of us as software developers. I'm currently reading "How to Win Friends and Influence People" by Dale Carnegie and loving it, but can't help but thinking in the back of my mind that somehow all these rules and guidance he has for being a decent human with other humans are extremely challenging when (in some cases) you are FORCED to work with said incompetant collegue. I agree entirely with the authors wording around this point, including "frustrating", "exhausting", and "toxic". Call me an asshole but I'm an engineer, by definition I like doing things efficiently and to the point. Working with someone who can't be either is incredibly challenging. Would love to hear more strategies people have developed to deal with this. Reading comments here, I want to be clear: I'm not talking about some ego-based notion of "incompetance" like "I can write code better than you". I'm talking about the bigwig guy on your team with a big wallet who tells you the product should be implemented in XYZ because he read an artical about XYZ in a magazine and thought it was cool. > Dealing with people is hard. Dealing with uncertainty is hard. Dealing with uncertain people is harder. And that's what you're going to do as a software developer. Also this, haha. This post is gold. Nice work!
  • jooz 4y ago
    Reading this point I realize is the one Ive improved last year. After covid crises, many seniors left, and I find myself being the more senior. There a few others seniors around me, but they have been on the same place all their life, so Im the senior with most different experiences. I often propose/ask other teams to implement changes that I need. Is often challenging, the are contrary to change. Specially if it comes from somebody outside their current team. I follow this approach: - I try to convince them, with diplomacy. Often what I request is also good for them. - If they refuse some _internal_ changes I propose, I live with that. If that issue some day impact me, I will communicate with them by opening a ticket. If they dont work on the ticket, will be a project management problem, not an software engineer problem. - I limit my interactions with them through their interface (ex: REST API provided by their service). On this point I'm rigorous, because the interface is difficult to change once is used by everybody. In summary, if they have bad implementations or bad design, I try to contain inside a box. Some day a new guy will be able to solve those internal issues. But I trace a line on the interface they provide, and ask for an interface that make sense.
• bjornsing 4y ago
  Good write-up. But to me this reads more like “Everything I dislike about ‘software engineering’”, and this question pops up in my mind: isn’t there some way around all this? I know this is kind of an unpopular opinion, but I think an important reason we end up with this kind of work environment is that we have no formal division of labor into separate professions. Compare e.g. with healthcare: I sometimes jokingly explain the situation to friends by saying imagine if there was only a single profession called “Healthcare Worker”, and every hospital had to self organize “Hunger Games”-style. Everybody is hired as a “[Junior/Medior/Senior] Healthcare Worker” and then they battle it out to decide who gets to sit in the corner office, who gets to be a doctor and who gets to clean the toilets. Often it turns out everybody does a bit of everything, otherwise it’s perceived as “unfair”. When there is no rigid formal power structure people make up for it with “politics”. I think that’s to a large extent what’s happening, and it’s sort of consuming our lives…
  • zmgsabst 4y ago
    This is something I talk about with SDE teams I’m coaching: - we’re like a football team - and that means it’s okay we have different roles that utilize our unique skills - or because we need a single play caller - but that doesn’t mean your role isn’t important; QBs can’t work with no linemen - and managements job is to be high level direction, staffing, and play calling - but they need to step back and let the people on the field do business - and only bad managers don’t take feedback from the people on the field You can give the same speech about military units or professional kitchens; because it turns out the ways humans organize aren’t all that varied. I just wish we could get to a paradigm of “team building” instead of “fungible cogs in the process chart”. Both sides, employees and employers, would be happier.
    • bjornsing 4y ago
      > I just wish we could get to a paradigm of “team building” instead of “fungible cogs in the process chart”. Both sides, employees and employers, would be happier. Sadly I’m not so sure about that. If you’re mostly cleaning toilets in a hospital then you would benefit greatly from confusion about your role, so that you can have a bit of the compensation and recognition of a senior physician. In fact when there is a wide distribution of ability a clear majority benefits from this confusion. I think the reason it works in football is that (almost) anybody can judge ability, so the confused state cannot be maintained for very long. But sure, with exceptional leadership that will stick their neck out to “give credit where credit is due” you can get around this. It’s just very rare.
• tossaway0 4y ago
  Even if you don't agree with everything, or the tone, there's a lot to be said for what is expressed in this article. To the points about time spent and business value coming first, I would defend them by saying first that companies of different sizes operate with different requirements for their staff. You were hired to code, but in my experience the code is only important when it's serving the end goal of value. It's up to you to make sure that you're providing value, so be fluid enough to know when not to say, 'not my job'. As for the grueling time expectations, I feel a lot of commenters are reacting to environments like those you hear about game devs; of course that's not alright. But yes, if there's systems that you work on that no one else really knows about, you'll need to keep tabs on them pretty much all the time. It doesn't mean you need to check in all the time, it means you need to write code to tell you on weekends when your things need to be checked out. The job I have now could probably be done by some ninja coder for less, but they pay me because I know how to deal with everyone who doesn't code while I write my code.
• Existenceblinks 4y ago
  Legit lessons but deep inside I feel bad because after 10 years in this industry I found that no one listens to anyone, it's sort of a culture. One thing I don't listen to anyone is "clean code". When I see a job description "something something .. clean code" I always think "by whose authority?". Of course we shouldn't write a huge terrible function, but your a-lot-of-indirect-calls looks clean but it's not. it's 4 level deep to investigate something. > Domain knowledge is more important than your coding skills This is where I wholeheartedly agree with. As I'm tired of cargo cult, playing tools, solving puzzles for fuck sake. I pick a domain knowledge first when I want to learn a new language to see what I could write some useful (to many people) thing in it. Tldr; you as you go help the others, not just learning sake.
• fjfaase 4y ago
  Something I would like to add to the list (being in the field for 33 years): Discover that your greatest struggle is with your own deep rooted sense of insecurity, I think that software engineering, like no other form of engineering, has an aspect of creativity (source code), in combination with many (often hidden) single points of failures (bugs), where cooperation with others is essential, causing all your insecurities to be revealed. Either you learn to hide these or they drive you on a road to soul searching, possibly resulting in various forms of burn-outs, in alienation from your family and friends outside of you work circle, in changing your world view and/or losing your faith. But which might in the end result in a form of enlightenment. I am aware that there are some other professions where this also is the case. Just this week, I watch an interview with the neurosurgeon Henry Marsh. You can watch it here (with some Dutch subtitels and advertisements): https://www.npostart.nl/vpro-wintergasten/04-01-2023/VPWON_1342504 https://www.npostart.nl/vpro-wintergasten/04-01-2023/VPWON_1...
  • mansoon 4y ago
    Null space propagation toward. Viral outbreak of not.
  • moosedev 4y ago
    I'm enjoying that interview right now - thanks for sharing! I also identified with the rest of your post. I've felt regret recently for the career "potential" I lost to the inner struggle, and at around 15 years in, I think I understand these dynamics well on an intellectual level, but emotionally, I feel further than ever from being able to overcome them.
  • zerobrainwash 4y ago
    Could you expand a bit more about what you mean about hiding insecurities? Are you hiding them from yourself, or from others? I am reading this as learning to deal with your insecurities but not sure if that's what you mean. Do you have any advice in particular? I feel like my imposter syndrome takes so much mental energy that I spend a lot of it just worrying whether I can do something rather than just doing it.
    • 4y ago
• magicloop 4y ago
  I've got a couple of life hacks that have seen me through things quite well: 1. My short term goals are: good quality sleep (8hrs), daily exercise (30 minute walk), proper healthy good meals 3 times a day. 2. Work intensely for 40 hours a week. Then switch off, and then have a could not care less attitude until you next return. Most work environments will recognise the discipline and reliable work ethic and will leave you alone. Some environments will measure you by hours-attendance and will push you out or criticise your work methods. These are not healthy places. Anecdote: I was learning about climbing and the instructor showed us a thin climbing rope chord (emergency back up). He explained it was plenty to carry your weight but comically thin. What might appear that it "would never work" sometimes can work. Hence my above advice to others.
• rco8786 4y ago
  Pretty decent article (don't agree with everything, but for the most part) > Code is secondary. Business value is first. I wish I could shout this from a mountaintop. If there's one thing I could change about engineering culture it would be this. But then again I would lose my edge if everyone understood this, so maybe it's best that they don't Engineers: If you want to stand out in your career - take this to heart. Code is not the goal. Money is the goal, code is a tool to get the money. You work in a capitalistic business, whether you like it or not. Push your colleagues to build the thing that makes the business the most money, not the thing that is the "best" engineering solution. You will get tons of pushback on this - but eventually your pushing will bubble up to someone who works in "the business" (directors, executives, etc) and not just other engineers and they will invariably support you. This is your contrarian view now. This is your answer to Peter Thiel's question "What important truth do very few people agree with you on?". And you will thank me in 10 years.
  • fatneckbeard 4y ago
    money is not the goal. providing a useful and valuable product or service to customers is the goal.
    • xyzzy4747 4y ago
      This is incorrect. Without money you won't get salaries. And people will need to find another job (at a place that does value money).
      • croes 4y ago
        Money is just the middleman pretending to be the boss.
    • AnIdiotOnTheNet 4y ago
      That's how it should be, but our society has embraced the sociopathic interpretation instead.
    • ricardobeat 4y ago
• mypastself 4y ago
  Some good points here. But I also have to make some objections. > You’ll need to work around incompetence It’s amusing that the article never suggests you might be incompetent. No, no, it’s the “other person” whose incompetence needs to be well-documented. > Rare work-life balance. In other professions, your work day ends at 18:00, and you forget about the job. Not here. You will most likely always be online and checking the code, even in the evening. I’ve always tended to avoid this throughout my career, and my bosses and coworkers have always been made aware of that. Wait. Would I be the incompetent the author is talking about?
  • dinkumthinkum 4y ago
    I wonder why so many HNers think that only software people that work or think about work after 5:00? Many doctors, lawyers, teachers, etc do the same. There are many car mechanics that get off work only to work on their cars or other peoples cars talk a lot about what happened at the dealership or whatever. It’s really not that strange.
• nunez 4y ago
  I do not at all agree with the "it's not a dream job" section. Please name another career that pays you six figures out of college that doesn't involve several years of additional education, doesn't make you wear suits, is mostly non-life-threatening, is constantly in demand, and doesn't require special accreditations or certificates. If you're spending more than your 40 working and aren't on call, then that is on you 90% of the time, in my experience. I have definitely worked more than 40 some weeks when I'm pushing through something, but there have been plenty of times where I worked less. If you can't find advancement in your current role, then that's also on you. Not that this matters, as finding a new job in this industry is insanely easy relative to other professions, and they'll usually pay more for your skills. IMO, you should ALWAYS be thinking about what you need to do to get to the next level, if career advancement is a priority. Everything you do should be in service to demonstrating capability in performing above your station and providing business value/revenue generation. Brag sheets and being vocal help a lot. I am biased; I absolutely love what I do and wouldn't trade it for anything.
  • guina 4y ago
    I mostly agree with you but want to provide a little disagreement. It’s not a dream job everywhere for every person. Not everybody is able or has the ambition to put in the work needed to be a top earning or top skilled developer. And even if you are a lot of the “dream” aspect of the job will depend on what country you live in, even in a remote-first world. But if you’re in America it’s one of the last professions where the American Dream is still possible. It’s a trade, so the better and more experienced you get the more money you can demand if you’re ambitious. Software also scales better than any business so your work can have an incredibly high level of impact.
    • nunez 4y ago
      I agree that programming isn't a dream job for everyone, but I don't think it's right to make a blanket statement saying that it's not.
• xyzelement 4y ago
  I need to write my own post on this but the gist: 1) In the long run, benefit accrues to value generation. The "best developer" turning out "amazing code" that misses the business goal is generating zero value. It's a hard fact to swallow. Ideally you are someone who can both engineer good code and be at least a part of the brain trust that "aims" that code at value (solving biz problems and generating money.) That sounds obvious but most people don't even think about that. My rule of thumb is that unless you are actively involved in that - ie acting as a product manager to some extent - you are likely under-delivering for yourself. 2) your biggest limitations are within yourself and you don't acknowledge them. That's the classic "I identify as X and therefore don't do Y" mindset, where Y is the thing that would "unlock" your next level. Like if you are "a C++ developer who isn't interested in talking to customers" then perversely, learning how to talk to customers (and not learning the next C++ standard) is the thing that will let you double your comp. 3) Your attitude determines your outcomes. People who assume all work situations are shit (assuming that bosses are always evil, coworkers are always stupid, etc) end up in precisely those situations. If you have a more positive expectation (eg want to give and receive loyalty, want the company to go above and beyond for you and to go above and beyond for the company) you can find those work relationships too. (Btw that applies outside work as well. If you believe all women are evil you end up an incel, etc) 4) Work is a team thing, and the people matter. How you are with people matters too. Whether people are looking forward to or dread meeting with you has a huge impact on your productivity and therefore your career. Also, there's a Darwinian element you should recognize. If your team succeeds, your colleagues get bonuses and grow and that should matter to you, not just whether that happens to yourself. 5) You get paid for impact in the long run. This is related to point number 1. Sometimes your impact isn't code but persuasion. I once convinced a company to shut down a line of business and focus on other things. The value of that is much greater than any code I wrote. To make such impact you need to (a) have original perspective/insight and (b) convey it to people who don't have that insight! If you are constantly frustrated because you are misunderstood, you need to make a conscious effort to learn how to persuade people in person and in writing. And to recognize that it's a slow and difficult process that most people fear and therefore fail to go the distance. 6) The concept of work life balance is misleading and too simple a frame for good outcomes. The homeless guy under a bridge has a great work-life balance (0 work) but his life sucks. On the flip side, some successful people work tons of hours and have a great life - because they enjoy their work and they enjoy the financial benefits.
• jmfldn 4y ago
  Hard disagree with this.. "Elegant code, best practices, smart solutions, design patterns — these are done for the sake of your fellow software engineers who will work on the codebase after you rather than helping you fulfill the purpose of bringing value" The fact that business is about money is a truism. The other fact is that, good engineers care about that AND know that good engineering - which requires 'some' obsession with good code amongst other things - leads to faster iteration loops, less bugs, better maintenence, less incidents and SLA breaches. Do you know what they all equal? That's right, money. Believe me, crappy, inconsistent over-complex spaghetti code and poor engineering practices can really really hurt a company. As ever it's a balance of course. Every decent engineer understands the trade offs. For my part, I think about the business goals first and foremost and, to achieve those, I make sure my code is as simple, clear, testable etc as can be when realising those goals. It's often a dereliction of duty as an engineer to just get the job done without reasonable consideration of good practices. Building up tech debt? Sure, I do it all the time. But sacrificing what I know to be a good practice just to deliver? No.
• acedTrex 4y ago
  The value section is great, code is worthless unless it DOES something. I especially appreciate the aesthetic section as i constantly struggle to explain that concept to people on a line by line basis
• RomanPushkin 4y ago
  This looks so bad because author mixes up "happy hacking" aka programming ("Programming is a craft" - Stallman) with industry-only experience. If you haven't had a joy of building things on your own, just for fun, the world looks boring (and even depressing), as it's described by the link. However, the whole another universe uncovers if you remove "industry" concept that has been illegally attached to "software engineering" concept by Vadim. In reality a lot of cool stuff has been built outside of corps, managers, offices, deadlines. The whole Internet works on Linux. Many successful games were built by folks who wasn't even once employed as software engineer. Some of them earned millions and billions.
• GuB-42 4y ago
  As I advance in my career, I start to like the messiness of real life software engineering more and more. We all like starting from scratch, from a clean slate, but that's actually the easy part, it only becomes hard later, when the requirement have changed and you start to notice the consequences of the bad choices you made earlier, and then you try to leave, or restart from scratch. So you want the easy part and leave the hard part to others... But where is the fun in that? I went to programming because I like things like problem solving, and it is not problem solving if there is no problem. Digging into code that no one understands, that is not documented, working around limitations, finding what needs rewriting and what doesn't (with an emphasis on the "doesn't"), managing technical debt and deadlines without overworking yourself, etc... Now this is a challenge, this is interesting, this is the job I signed for even if I didn't realize at first. And don't let anyone tell you that these are not coding skills. These are totally coding skills, where code reading is as important as code writing, where you have to be able to code with any API, in any environment, in any style. Not just the narrow subset of algorithms (which is also important).
• astura 4y ago
  >It's not a dream job Its a dream job for me and would be for 90%+ of my friends. I suspect anyone saying this has very little life experience. All jobs involve work (duh) but software pays very well, is in demand, only requires a bachelor's degree, and is very chill with a very good work-life balance. If you're working unpaid overtime then get another job. I've only worked about 3 hours unpaid overtime in my 16+ year career. I've willing worked paid overtime a few times, but not often. If software isn't close to a dream job then I'd like to know what is.
• lionkor 4y ago
  > Rare work-life balance. In other professions, your work day ends at 18:00, and you forget about the job. Not here. You will most likely always be online and checking the code, even in the evening. Im not working a second im not being paid - its fun, sure, but its not that fun that i'll work for free.
• aryehof 4y ago
  Touching on domain knowledge, reminds me that there are different types of software applications, yet I rarely see any differentiation. There is just “software”. Much of the audience and discussion here on HN revolves around applications in computing, the computer and data sciences, and software infrastructure. For this purpose, “external” business domain knowledge and value is of little interest?
• pjmlp 4y ago
  Pretty much to the point, interesting article.