Pretty decent article (don't agree with everything, but for the most part)<p>> Code is secondary. Business value is first.<p>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<p>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 <i>tons</i> 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.
<p><pre><code> 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.
</code></pre>
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".
I do not at all agree with the "it's not a dream job" section.<p>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.<p>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.<p>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.<p>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.<p>I am biased; I absolutely love what I do and wouldn't trade it for anything.
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:<p><a href="https://www.amazon.com/dp/1484290410/" rel="nofollow">https://www.amazon.com/dp/1484290410/</a><p><a href="https://www.whyprogramsfail.com/" rel="nofollow">https://www.whyprogramsfail.com/</a><p>That can mitigate that a bit.
Something I would like to add to the list (being in the field for 33 years):<p>Discover that your greatest struggle is with your own deep rooted sense of insecurity,<p>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.<p>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.<p>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): <a href="https://www.npostart.nl/vpro-wintergasten/04-01-2023/VPWON_1342504" rel="nofollow">https://www.npostart.nl/vpro-wintergasten/04-01-2023/VPWON_1...</a>
>> 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.<p>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.
Hard disagree with this..<p>"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"<p>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.<p>Believe me, crappy, inconsistent over-complex spaghetti code and poor engineering practices can really really hurt a company.<p>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.<p>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.
<i>> Meetings are there to ensure that everything is going smoothly and on schedule.</i><p>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.<p>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.<p>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.<p><i>> You might not like it, but the information must be shared for the system to remain efficient.</i><p>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.<p>But I dare say that if the meeting is there simply to find out that there is a problem, you are doing something wrong.
Some more:<p>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.<p>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.<p>All projects are chaos, learn to accept that and to navigate it.<p>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.
"Estimations will be asked even when you don't want to give them"<p>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.<p>Time or scope, at least one of these things needs to be flexible, and stay flexible until the work is done.
> 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.<p>Yep<p>> Rarely you're building something you love. More often than not, it's tedious work that needs to be done<p>You should switch jobs. The majority of my jobs were building something I love<p>> It's hard work. You're sitting behind your computer most of the day.<p>That's not hard. That's what I would do even if I didn't have a job.
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.<p>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.<p>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.
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.<p>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'.<p>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.<p>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.
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.<p>I'll never experience that again. 8(
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.<p>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.
Some good points here. But I also have to make some objections.<p>> You’ll need to work around incompetence<p>It’s amusing that the article never suggests <i>you</i> might be incompetent. No, no, it’s the “other person” whose incompetence needs to be well-documented.<p>> 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.<p>I’ve always tended to avoid this throughout my career, and my bosses and coworkers have always been made aware of that.<p>Wait. Would I be the incompetent the author is talking about?
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.
As I advance in my career, I start to like the messiness of real life software engineering more and more.<p>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...<p>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.<p>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).
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.<p>However, the whole another universe uncovers if you remove "industry" concept that has been illegally attached to "software engineering" concept by Vadim.<p>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.
After 10 years in the industry I agreee with almost every bit.<p>Soft skills are never taught, rarely checked during interviews, but might well be themost important ones.
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.
> You’ll need to work around incompetence<p>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.<p>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.<p>> 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.<p>Also this, haha. This post is gold. Nice work!
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?"
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?<p>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.<p>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”.<p>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…
> 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.<p>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.<p>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.
> Meetings are there to ensure that everything is going smoothly and on schedule.<p>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" (<a href="https://en.m.wikipedia.org/wiki/Roemer%27s_law" rel="nofollow">https://en.m.wikipedia.org/wiki/Roemer%27s_law</a>). Health organizations will push patients to get extra, often unneeded, treatments if they system has extra slack.<p>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.
> Domain knowledge is more important than your coding skills<p>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.
>It's not a dream job<p>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.<p>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.<p>If software isn't close to a dream job then I'd like to know what is.
>Domain knowledge is more important than your coding skills<p>It depends. For hiring I would focus much more on coding skills than domain knowledge.<p>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.
Touching on domain knowledge, reminds me that there are different types of software applications, yet I rarely see any differentiation. There is just “software”.<p>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?
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)
> 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.<p>Im not working a second im not being paid - its fun, sure, but its not <i>that</i> fun that i'll work for free.
The value section is great, code is worthless unless it DOES something.<p>I especially appreciate the aesthetic section as i constantly struggle to explain that concept to people on a line by line basis
One thing is missing from this list.<p>No one ever gets promoted for removing features.<p>Any code base that has had a few birthdays has stuff that needs to be removed and might not ever get removed.
> Code is secondary. Business value is first.<p>Eh, what a predictable and boring attitude :/<p>This advice makes sense in a company environment, but there's so many other motivations to write code than just 'business value'.<p>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.<p>My counter-hot-take: focusing on business value makes you a worse programmer.
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.<p>> Domain knowledge is more important than your coding skills<p>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.
Good list !
The one thing I would add or emphasise: Is <i>communication skills</i><p>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)"<p>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 !<p>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.<p>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.<p>TL;DR: If you want to be an effective or standout coder: Focus HEAVILY on your communication skill.
I need to write my own post on this but the gist:<p>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.<p>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.)<p>That sounds obvious but most people don't even think about that. My rule of thumb is that unless you are <i>actively</i> involved in that - ie acting as a product manager to some extent - you are likely under-delivering for yourself.<p>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.<p>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)<p>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.<p>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.<p>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.
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.<p>Domain understanding is just understanding, it's not related to HOW you do it effectively.