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.
I learned this at some point while working in manufacturing. No one responsible for how much you get paid really cares how clever your idea is unless it makes the company more money.
For me, the game theory gets pretty advanced at this level.
My strategy now relies on enriching myself via equity and careful product decisions so that I can then go start my own software studio and do things my way. Presumably, this is what our leadership wanted all along.
Trying to get my rush experimenting with new ideas under the current employer is really only shooting myself in the foot with regard to this long term plan. Any experimentation is reserved for side projects and weekends. At this point, I only bring "code" ideas to the team if I think they will legitimately improve the business in some eventual way that a non-wizard can understand.
The irony is, I started and sold a consulting business. We got to do some things our way, but we still had to make money. Overall, I say do it, but I made choices I never imagined I would have to make. So it goes.
This is really the next layer up in the ‘galaxy brain meme’ of this thread. The understanding that the people that dissuade you from gold plated engineering solutions are not some inherently different monsters. Rather, they’re doing at least roughly what you’d do in the same situation.
It’s the central tension we always had. Can you do enough your way, and as you grow, your teams way while still making money. Hackers have an ethos and working for big corporate behemoths often means compromising that ethos. I feel we did, and still do, a good job. You can get rid of so much red tape, focus on quality, have a really fun culture etc. and if you hire pragmatic folks who accept they get all of that in return for doing the make money part of consulting it can be a ton of fun and very rewarding. But the owners and managers in the business are always balancing it.
It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity.
Technical debt is a real thing. As is "decision debt" (not sure the official term; I mean where you make the wrong long-term choice because you didn't spend enough time on research / prototypes. For example:
* Using Python because it lets you get something working fast. Oops three years later you're locking into Python and your app is slow as hell. You now spend all your time profiling instead of adding features.
* Producing documentation and commenting code. Don't need it now. 10 years later everyone that worked on the code has left, nobody can understand it and you have to start from scratch.
* Investing in tooling.
* Using Bazel. It's so complicated! We'll just use Make. 5 years later a CI run uses 300 compute hours and 6 wall hours, even for fixing a typo in the docs (these numbers are not made up).
Does those things produces no business value in the short term. But it definitely does in the long term.
> It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity.
I'm not. I didn't say anything about speed. I am talking about deciding what to build. All of your examples lack the context of what is the best at making money for the business. You can't properly make a decision about addressing any of those things without considering the bottom line effect. Fixing performance for the sake of speed is not the right decision, unless your users are leaving because of speed and causing dollars to be lost. Technical debt is everywhere, prioritize fixing the debt that is causing monetary harm, ignore the rest of it.
"build the thing that makes the business the most money" is exactly what I said. And yes there's obviously plenty of nuance to that, especially when it goes "meta" and you get into tooling and platforms and tech debt and whatnot. But as a guiding principle it is inarguably advantageous and surprisingly rarely held (in my experience).
- Don’t rewrite the architecture with microservices when the monolith is working fine
- Avoid rebuilding the company blog on the latest CMS unless there are good business (time/money) reasons to do so.
- Choose boring technology, which would be the ones that most of the people on the team already know, and probably not the cool new language you heard about last week. Avoid fragmenting the tech stack to keep things operationally simple.
This is just a guess though – if you have some examples from your own experience it would be great to hear about some!
Can't disagree with any of those really. I guess it's really hard to draw out general conclusions about these sort of things when the specifics really make a difference. You can pretty much say "spend your time wisely" which is not very actionable.
For instance on your last point - I've heard that used to argue against any new technology even if it solves real problems. Rust, Bazel, React, Typescript, etc.
I would go so far as to say some of these general principles can be harmful because they are mostly used as a lazy way to defend bad decisions. E.g. "premature optimisation" is more often used to justify ignoring performance entirely than it is to stop people writing things in assembly or whatever.
Premature optimization is much more useful as a deterrent for stuff like building complex data structures and processes to speed up looping through like 100 items.
"But it might be a million items later!"
Yeah, or the company might pivot before we ever go live with this feature. Just slap a for-loop in there and get on with your day.
You should pick short term. Pretty much every time. The tradeoffs just don't make sense the other way.
There's a 9/10 chance the thing you're working on will fail or not achieve any sort of scale. Opting for short term productivity will let you find this out faster, and save you millions of dollars and years of time over your career.
When you hit that 1/10 product, you will experience some pain. But you now have enough information to justify dumping the resources (including political capital) into a proper long term solution.
> When you hit that 1/10 product, you will experience some pain.
There is a neat little trick I learned. Wait until leadership is under fire from customers and/or investors regarding the thing you thought might become an issue, and then present your solutions. Once you have proper buy-in, you can likely move way faster than by trying to constantly side-channel things through existing processes.
Spinning hypothetical tales of doom in order to be granted permission to build something shiny is probably the #1 thing that slowed me down in my career.
> It's amazing how many road blocks an executive trying to save their reputation can clear for you.
Precisely. The grandmaster software engineer learns to manipulate organizational inertia, fear and egos in order to achieve their goals. Simply detecting when someone has their heels dug in on something will take you about 80% of the way there.
Showing up to the 5 alarm fire with a perfect solution that can be deployed within 48 hours will make you look infinitely better than if you engage a months-long headbutt session with your managers about potential fires. Prepare your magic in secret and reserve your hope. If you are right, it will pay out. Be patient.
> Using Python because it lets you get something working fast. Oops three years later you're locking into Python and your app is slow as hell. You now spend all your time profiling instead of adding features.
Or your app continues to be perfectly usable like almost all Python apps because you’re not doing something CPU-bound in unoptimized code, and you’re not seeing YouTube/Instagram-level growth.
Performance is a real consideration but the better way to approach it is to make sure you understand the bottlenecks in your architecture and have a reasonable plan for replacing code when you need to. I’ve seen more failed apps in fast languages because the developers took so much longer to build things that they never found what users wanted or the performance problems they actually had weren’t what they expected so their Go code being 10% faster mattered less than taking months longer to reach feature parity.
There are situations where performance is critical on day one, of course, so part of your value as a senior engineer should be recognizing which situation you’re in and balancing those needs with your staffing levels, too. Your Bazel/make example is similar: if you’re seeing that kind of performance hit either something’s gone badly astray or you have grown to the point where you can afford to have someone dedicated to setting up more advanced tooling because they’re supporting hundreds of developers.
> Or your app continues to be perfectly usable like almost all Python apps because you’re not doing something CPU-bound in unoptimized code, and you’re not seeing YouTube/Instagram-level growth.
Honestly I have yet to use a significant (like >10k line) Python app that wasn't really slow. It definitely doesn't require YouTube scale.
"Just optimise the bottlenecks" is generally a myth in my experience. Most programs are all bottleneck.
And sadly those aren't problems or concerns for many/most folks. It's only an issue for those that haven't moved on after 2-5 years. Sad but true. Short term thinking is our present reality and way of conducting "business".
> "just get it done quickly" vs "take your time and do it right"
There is no such thing as "do it right". There's your flawed and biased perception of what's right, which doesn't take unknown unknowns into account.
> Oops three years later you're locking into Python and your app is slow as hell
Been using Python more than a decade, never had this problem. App slow as hell is always an eng culture problem. Shitty engineers will write slow code in any language. Don't do HFT in Python, don't write web apps in C.
> Producing documentation and commenting code. Don't need it now. 10 years later ...
The need for documentation doesn't skyrocket from 0 to 100 overnight.
Don't need it now? Don't write it.
Starting to feel the need? Start writing a little bit.
The problem is not the decision to not write documentation. The problem is not re-evaluating this decision in 10 years.
(another problem, based on your take, is treating documentation as binary: we either don't do it, or we're going all in)
> We'll just use Make. 5 years later a CI run uses 300 compute hours and 6 wall hours
Do you think every team that uses Make has this problem? Again, sounds like it's a team problem, not tool problem.
I had a boss for a while that took the opposite view. He just wanted to do interesting work. He was good at politics so he did, but the level he would have risen to in management if he had focused on business goals and money instead of fun work would have been much greater. But he also wouldn't have still been doing daily technical work which is all he wanted. We acknowledge that fun work can be part of total compensation, so accepting lower career advancement in return for more of that compensation doesn't strike me as unusual or a problem.
I guess that depends on what you mean by "stand out" then.
It is possible to stand out technically without standing out in a "how high in the org chart can you go" contest
Code and business value are worthless. Boss approval is literally everything.
It really doesn’t matter if your ideas make a ton of business sense if they are in conflict with your direct manager or any part in the chain of hierarchy. As long as they don’t like what you’re saying - you’re literally worse than worthless. Often this is because your idea isn’t their idea - therefore damage to ego. Damage to ego means get that guy out of here and make sure I don’t hear more from them.
People need to understand that you’re hired for a job. You’re a glorified and well compensated code monkey. Even at $1m/yr - still a god damn code monkey. You jump when they say jump.
I’ve yet to meet any hierarchy chains that are truly open minded to a low level IC saying anything that counters them. I’ve worked at quite a few places too and talked to a lot of folks about this.
You’ll thank me in ten years because you’ll become a bootlicker and actually make progress in your career rather than being stuck in senior/staff until you burnout from the industry.
Bosses are humans. They can be wrong. They can be convinced. Even manipulated, if that's your game.
> you’re hired for a job. You’re a glorified and well compensated code monkey
Only if you choose to treat yourself like one. I'm hired for my domain expertise that my bosses lack. I can understand 60-80% of their domain, they can understand 5% of my domain. When I'm saying that feature that they want is a nice-to-have and I don't want to build it unless I see evidence of it's value, they usually listen.
> I’ve yet to meet any hierarchy chains that are truly open minded to a low level IC saying anything that counters them
I worked at multiple startups (between 4 and 100 in size) and I always had a voice, even early in my career. Maybe you're the problem?
> you’ll become a bootlicker and actually make progress in your career rather than being stuck in senior/staff
Where exactly does the bootlicker progress? A code monkey doesn't become VP/C-level through bootlicking, there are plenty others with much better soft skills. At best you'll be a code monkey turned manager (which is worse than staff).
Unless you're in a <10 headcount everyone-does-everything startup, by the time work reaches software engineering it's already been determined as having good business value. It's rarely a software engineer's job to challenge that determination unless new information emerges that wasn't factored into the original decision.
Also, maybe my perspective is skewed from only ever working at gigantic companies but what usually grows a career is making your manager's life easy - becoming someone who reliably gets shit done on time and without drama.
I think most engineering teams will have a "backlog" of tech debt. Some are things they want to do (the original implementation is icky but could be lived with for years until requirements change) and some will save the team hours per week in distractions/maintenance.
Being able to evaluate the actual impact of the "tech debt clean-up" and pick the one which helps the business will absolutely set you apart from your peers.
I think you massively underestimate the number of startups with product engineers.
It's becoming a much more popular approach with many high-performing startups, even up to the 250+ headcount tiers.
The execution by swe can still take 10 times longer depending on if you go with a proven, quick and dirty straightforward YAGNI solution vs reinventing the wheel in latest cool fad, with hundred layers of abstractions and configurations in beautifully crafted code in the most poetic rube goldberg machine you have ever seen.
You can probably also extrapolate this advice to most jobs that involve building or manufacturing something. The way you make it, the techniques you use, the practices you put into play... are all secondary to whether what you're building actually serves a purpose/fills a need.
And that's equally true of everything from programming to design to writing. The value of a newspaper article is often the story it tells, not the actual way it was written. Same with a video, film, tv show, design, or whatever else. Most people don't care how good your technique is or how elegantly the product was made, they care about whether it does something they care about.
This works in non-dysfunctional organizations only. In dysfunctional ones, the inmates are running the asylum and you will be scoffed at if your code doesn't follow the latest trends and buzzwords (e.g. functional programming). Nobody represents the business value - the product owner cares only about features being delivered and doesn't care (or, usually, understand) how the engineers do it, and the engineers are busy outnerding each other with "cool" tech. If you'll propose simple solutions using old and reliable tech, the team will think you're a lazy moron.
> Money is the goal, code is a tool to get the money.
This is an obvious and empty statement if it's not used in specific cases. Unless you have something new to add in the "how to get money debate" the distinction between "code" and "value" is irrelevant.
When I've heard this, it's typically way to trivialise engineers and shut down discussion. "I don't understand how this contributes value, therefore all your contributions are worthless."
This same argument permeates in lots of other facets - especially things like compensation. Most tech people I feel do not realize that their compensation is not based on their actual “worth” but their worth to the employer cutting the checks. It is all about money and nothing else. I know people that make close to 7-figure total compensation package who would fail job interview in 98% of the companies (this number is actually closer to like 99.23%)
>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
MBA-driven development when
You can never go wrong when optimizing for profit above all else.
But if I don't build it with Rust with pure functional programming, how could I scale type correct, shared-nothing architecture? Who cares if customers like it? It could be a disaster if Coq cannot verify its correctness! ;-)
>Money is the goal, code is a tool to get the money. You work in a capitalistic business, whether you like it or not. Pu
Capitalism and money are actually only the means to an end, to achieve the best possible for society. But as is so often the case, at some point the means becomes the end.
Totally incorrect, at least in a business context. If it were the case, you would build that useful and valuable product and then give it to your customer for free. But you would never, ever, do that (unless it was specifically as a loss leader for other products) because making money is the goal.
Only if the problem is pervasive and people are paying money for it. Providing value just increases the probability that you will make money. You can have a very valuable service/product and fail miserably because you have no idea how to run a business and lack the know how and fuel to power awareness activities like marketing and sales.
I'll have to disagree with this one, that's what that point is about. Great things can be achieved by focusing on UX and providing real value, but these are means to an end, and the business' end goal is still making money. Most of the time [1].
Can you whip up a quick & dirty feature that might generate more revenue if released tomorrow? You can bet it will be done. At this moment the engineers who know when/where to compromise stand out.
[1] companies with a strong ethos or social mission do exist. If you find one that makes you happy, hold onto it :)
There is so much packed into the phrase "the goal."
- Is it the business owner's goal? Depends on the business owner.
- Would the CEO have a better company if they focused on building something great rather than extracting money? Depends on the industry (the premise of capitalism is yes, but unfair markets are a thing)
- Is it (betterment of society through engineering) a valid personal goal to have on a strictly moral or ethical level, with no need of evidence or efficacy? Sure, absolutely
- Are people who focus on "extracting money" sheisty MBA types who lie through their teeth and exaggerate every number and kill the company in the process of trying to self-promote any random thing they can control? Sounds like a leading question...
> 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.
On the flipside, you can be like me and be "meh" about business value (or at least, not a maximalist about it) and treat code as the point and fun/art/etc (easy to do with an FP language, for example). You'll still deliver value and even squeak in some fancy code that isn't the best business value.
The result? Over the years, your employer(s) effectively subsidize your code-for-fun's-sake using the money they make from business value others focus so much on :)
"What important truth do very few people agree with you on?"
For me it's that Apache is the best web and proxy server, Java is the best programming language and platform, Eclipse is the best IDE and never use anything made formerly or currently by Russians including nginx and JetBrains' stuff.
I mean irrespective of Apache/Java/Eclipse, saying to never use something made by someone just because it was developed by a company/people of a certain nationality is just silly.
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".
I lead a fairly large team and I agree with this comment. It is certainly possible and healthier to disconnect from work after 17:00. Unless you’re in charge of coding a nuclear reactor core or similar, your CRUD app can always wait. A streamlined on-call process should be in place instead.
Taking care of your headspace and unwinding at end of the day should be one of the most important routines in a programmer’s life.
> A streamlined on-call process should be in place instead.
Honestly even 99% of non-nuclear reactor code doesn't need on call. Most of the time it can wait until the morning. Amazon? Sure, have on call. Your app that's used by businesses during the business day? Fix it tomorrow.
The part of the paragraph that really bothered me wasn't the hours, actually. It was the implication that you would be expected to code during those hours. Even when I've been on-call, I've never expected to write code, outside of business hours, during my on-call shifts. Update configuration? Sure. Roll back a broken deployment? Absolutely. But if devs are writing significant amounts of code (beyond 10-line patches, or updates to config files) in order to put out operational fires, that's a big red flag. It means that the codebase hasn't been designed to be easily changed with configuration. It means that deployments are so difficult, it's easier to try to write a patch in the moment than it is to roll back and see what went wrong in the morning. Furthermore, any code that is written under that kind of pressure isn't going to be high quality. It's going to be code that does the minimum necessary, with no documentation or unit tests. It's tech-debt equivalent of a high-interest payday loan.
It's not always the job. Sometimes it's the person. Had a junior developer I literally had to shoo away from his desk at the end of the day, otherwise he'd keep working until 9 PM.
I tried to tell him: Nobody asked this of him. He didn't need to prove himself, it wasn't on his back if we didn't meet the deadline, it wasn't worth sacrificing his health and the relationship with his wife and more than likely burning out before 30.
I've started billing that. Not always, rarely in full, but I bill some of it. It's not just for the money but started more like "what exactly do I work? Best way to know is to bill it".
Unless you're a contractor, exempt salaried employees are exempt from overtime requirements and thus typically can't bill for overtime, unless their employer likes burning money for some reason.
It goes both ways though - if I can't stop thinking about something that's just not quite working yet, then I haven't/can't 'clock out'.
I think I'd like a job with truly flexible hours: work all evening on something if it's occupying my thoughts anyway, but then get a full 'evening' to chill, full night's sleep, and start the next day when I'm ready. I can do the former, but I'm still going to be expected to dial in ~to pointlessly summarise it~ for stand-up in the morning. (No I don't have young children, yes yes this wouldn't work for everybody.)
That might be the case in startups (one of the other articles on the same author's page is "Lessons learned from becoming CTO of a small startup"). One of the reasons why some developers choose to work for faceless big megacorp rather than cool aspirational startup is that there are megacorps where you log off and go home at the end of your working day, along with everyone else.
Ya this is rediculous. Ive been logging off for years at 5pm, sometimes even 4pm. I don't work for free. Sometimes I have had to work at night but that means I take a few hours off another day when it's slower.
I often think about code at night but only in the context of a personal project.
I was trying to get my current company to cover our cell bills because everyone messages us all the time at all hours, even past midnight. When I talked to the c levels they said there's no expectations to reply off hours so they won't cover our cells because they don't want to promote that atmosphere. I turned off all notifications and it's much better tho I think people are starting to get annoyed
This is a part of many company's culture I hate. Where the "official stance" is work-life balance but the reality is everyone is putting in overtime all the time with emails and chats on their phones.
When I start a new job nowadays I don't install teams or slack or connect my work email to my phone. If I have messages waiting in the morning I just address them then. If anyone complains, oh well.
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).
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.
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?
If you're so uninterested by your work that thinking about it after 6pm
makes you sick, why did you pick it?
Doing anything continuously for long periods without rest is unhealthy, and leads to both declining physical and mental health. Working 10-12 hour days is something that you can do for a short burst, but if you're doing it for months on end, it will negatively impact you.
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
I think about code too, but it's rarely work code. It's usually about some hobby project or interesting algorithm that I've picked up.
What if your job was open enough that you could find dozens of interesting
fun things to code on the side?
No job is that open. From your other comment in this thread:
I have some days packed with meetings and calls, and I actually find it
refreshing/relaxing to work on more down to earth matters in the evenings or
weekend.
I guess I'm fortunate in that I don't really have that many meetings or calls, and I don't have to spend my weekends and evenings doing programming. I get to do mostly programming during the day. Then, in my off hours, I have the option of programming. But I also have the option of doing other things, like watching TV or reading a book, or going for a bike ride.
I guess with a sample size of 1, I would also be tempted to make sweeping generalizations on an entire industry if the sole same was my own experience.
Because there is a very strong negative correlation between overworking and productivity / quality of work. When I've been line managing people I find that if they work over 40-45 hours a week their actual productivity (as opposed to their self perceived productivity) starts to fall off a cliff after a couple of weeks, so I ask people to only work their hours. I've sometimes had to implement technical measures to enforce this when someone gets too obsessive about their work(and have done it to myself a couple of times!). I've never had to fire anyone for working too much and dragging down productivity in a team but I've come close a couple of times.
> Because there is a very strong negative correlation between overworking and productivity / quality of work
Working outside of business hours is not the same as overworking.
I have some days packed with meetings and calls, and I actually find it refreshing/relaxing to work on more down to earth matters in the evenings or weekend.
Sometimes I even take vacations just to code on some work-related projects that I find super interesting and wouldn't have enough focused/dedicated time on normal business days.
Overall the whole hard distinction between work and non-work is overstated IMHO. I choose my work places because I genuinely like what I would do there.
I will even go further: If I end up with colleagues that are _not_ genuinely interested in what we do to at least think about interesting problems in their free time, then it's a bozo job, I don't want to work with these people. Nothing great has been achieved by teams where people shut down their brain after 6pm.
Now don't get me wrong, I understand that there are gruntwork places out there, where the job is writing braindead CRUD apps all day long, and I wouldn't want to think about it after-work. But then again, I wouldn't work there on the first place.
I'm 62 and have been in this industry for 40+ years. The BIGGEST regret in my entire life has been the time I spent as a young man working stupid hours on "super important" jobs, and missing seeing much of my kids growing up.
First, very funny that with each comment the author is older.
Second, I’m 33 and regret yet. I misunderstood every customer is king with every customer is important and has the right to call me outside of work.
I worked 7 years about 60-70 hours each weak for customers which „are so important“ to work at weekends.
No one will give you the time back you could have spend better by developing yourself, family time or staring your own carrier. But working for a company is most of the times lost time.
> I choose my work places because I genuinely like what I would do there.
That's great and so do I, but I still don't see that as reason to work in my free time. I do some personal projects as well, and those are usually even more interesting but also more beneficial for myself.
Of course I still think about stuff from work now and then, maybe I see an interesting solution when casually surfing the web, but I'm not going to do more about that than write a note for the next work day.
> Nothing great has been achieved by teams where people shut down their brain after 6pm.
Citation needed
Edit: Also most teams never work on the next exceptional thing that will be remembered in 30 years, so why work as if it was?
> If I want to go hack on some Clojure after work, when the day job is in Python, then what's wrong with that?
That is of course perfectly fine, but to me that represents a not-so-ideal fit between your interests and your job.
Realistically, you will spend more engineering time on your job than on your hobby project.
From my experience, that means my out-of-working-hours projects tend to be driven by needs or limitations I encounter at work.
I then find it more optimal to embrace and leverage that relationship between during-working-hours and out-of-working-hours projects.
This is the best of both worlds, you get work on more green field projects, have flexibility to choose what you work on, under the constraint that it solves something for your job, but under the assumption that your side projects are anyway often inspired by work, it's a fit by construction.
Let me give you an example:
Some years ago I used to manage some high performance computing cluster, with storage nodes attached to compute nodes as the jobs were very IO intensive. We used glusterfs, which at the time got acquired by RH and maintenance stopped. Me and a coworker started to dig into glusterfs to solve our issues. We spent months reading the code on our free time, reading papers on distributed filesystems, fixing issues in our fork (hoping that RH would pick up maintenance after the transition). That's an example of an out-of-working-hours project, inspired by work, that got used at work, and thus counts as work, while still being very interesting.
This is just an example, but overall I kept that mentality and have been doing that kind of things for more than a decade. You just need to find the right job where you have 1) interesting problems to solve that inspires you to do more 2) the freedom to push your projects 3) the drive to work out of office hours to prove that your projects are worth it and push them.
All the colleagues I have respect for do the same. And someone that does not have this spirit, for me, is not someone I want to work with.
That is of course perfectly fine, but to me that represents a
not-so-ideal fit between your interests and your job.
If the day job were Clojure, I'd be hacking in Python in my spare time. Or some other language (Rust, Haskell, etc.). Or not even hacking at all, but reading a book, or doing something else. The entire point of having hobby projects for me is that they're not what I'm working on during the day. They're an opportunity to broaden my horizons.
Me and a coworker started to dig into glusterfs to solve our
issues. We spent months reading the code on our free time, reading
papers on distributed filesystems, fixing issues in our fork
(hoping that RH would pick up maintenance after the transition).
That just sounds like a lot of unpaid overtime to me. It sounds like you enjoyed it, but I'd find that experience absolutely miserable. Working intensely on a project is great, but I need time where I'm thinking about something completely different, otherwise I burn out fast.
The difference is a a single question: “do you have family/kids?” This is also the main reason for ageism in the industry, where employers prefer to hire younger people.
I love programming, but I love my family even more.
And that's why I only work about half the day during 9-5, and the other half after 6pm. Because little kids don't disappear from 9-5pm and I like spending time with them.
> Sometimes I even take vacations just to code on some work-related projects that I find super interesting
> what we do to at least think about interesting problems in their free time, then it's a bozo job
> Overall the whole hard distinction between work and non-work is overstated IMHO
Look, I continue to code and study in my free time, and I am still passionate about learning SoftEng and CompSci fundamentals, but the shit you're saying sounds super-sad and I definitely wouldn't want to work with someone who takes vacations to work on _work_ problems, either.
I'll take a seasoned and passionate engineer who has a family (even though I don't have one!) and has to work around that any time of day. In the vein of what GP was saying, bounds on limited resources like time can produce very effective work habits and conversely, seeing time as an unbounded resource (which is a phallacy anyway) sounds like the recipe to have a culture of sociopaths.
- extremely privileged and never had to grit your teeth to pay the bills
- going to have a rude awakening when the crop of younger millennials and Gen Z hits your workplace and you realize these bright young things with dreams and desires are only in software because it’s one of the few lucrative careers left in this proto-fascist shithole of a dying civilization.
This is pretty extremist. If you think this is proto-fascist, you must not be aware of what fascism is like. As far as a “shithole” or “dying” civilization, I mean what is an example from of civilizations that are tremendously better or more “living?” I would agree that leftist culture is pretty depressing but I GenZ is a good example of the kind of generation that subsequent generations will react against, though it takes time. As far as Gen Z “hitting the workplace,” the kind programmers you’re talking about don’t seem to know a lot about computing other than React and mashing up APIs; I’m not sure “older” engineers that know things need to be that concerned.
Income inequality and social stratification have both increased dramatically in my lifetime, and QoL and resilience of various systems necessary for civilization have decreased.
As far as fascism goes, as you say, these things need time… but I’m sure a yet unwritten history book can enlighten you, right next to the passage on the gen Z backlash.
This is not really relevant, I was merely provoking emotional response for rhetorical effect (a useful and effective tool in the business/realpolitik toolkit)
And I’m sure these younger engineers are happy collecting their paycheques, scheming their schemes and thinking of what to disrupt next with all the free time they have because they roll their eyes at guff like the parent comment. Maybe that’s how we can all be happy.
You are not describing interest, you are describing obsession.
I love being a software engineer, still, my family is orders or magnitude more important than my employer’s codebase. I really don’t care about my code architecture issues at work when I play Legos with my son or when I ask my wife if she had a good day while cooking together.
And I say that while currently working for a good employer on interesting topics.
> You are not describing interest, you are describing obsession.
I'm describing passion.
> love being a software engineer, still, my family is orders or magnitude more important
It's not mutually exclusive...
I wake up at 6am, usually because that's the time my son wakes up. I spend around 30m with him until my wife takes over.
Then I work on some stuff from 6:30 to 8:30 before the rush of the day starts.
My wife does her morning yoga starting at 8:30 so I take care of my son from 8:30 until the nany arrives at 9am.
I do my work day WFH (with some pauses to play with my son or chat with my wife) until 6pm, then stop to spend time with my son before he goes to bed around 7pm.
I cook, eat and discuss with my wife between 7pm and 9pm.
We usually then head to the sofa where she watches a movie and I sit next to her reading/coding.
She will go to bed around 10pm, I usually continue to work/code/read until 11pm/midnight.
3 times a week I swap the cooking part to go running for an hour. Or I do it at lunch time.
Overall I spend quite some time with my wife and child, while still working between 2 and 6 hours more per day.
I really don't think I have a crazy schedule, nor that I don't spend enough time with my wife or child, or doing sport.
I think the interesting parties to answer that are your wife and kid (in the future). There is subjectivity in what constitutes “enough”.
And there is also quality vs quantity. Each family is obviously different.
As friendly advice, have an open conversation with your wife about that. Speaking from personal experience, I definitely had months where I thought I was balancing my time well enough and my wife disagreed.
Every conversation in this thread where someone implies what is "enough" "passion" or "accomplishment" makes me agree more with unionizing the industry.
It's as though the absence of religion in modern life has left a vacuum of comradery and dogmatism, so they let work fill it.
To counter your final sentence. Europe has an absence of religion and has no such work-life balance issues as America. (Speaking from experience on both sides of the big pond)
I don’t see much wrong with your schedule if it suits you.
Keep in mind that many people are passionate about multiple things and it is ok that they are not coding related. Please, just don’t assume I am not passionate about my job if I spent “only” 8 hours a day on it on average. There are just more things I am passionate about and I have only one life to live.
Because there is more to life than coding? Family, friendship, health, leisure… Other professionals actively try to separate these from their daily duties, regardless of whether they like their jobs.
Because I need money to exchange for goods and services in order to live, particularly in order to maintain housing and healthcare.
I would love to be paid to pursue my passions full-time, but that opportunity has not yet arisen. So I split my time accordingly between doing what earns me a living and doing what I actually enjoy in life.
for some people having strict working hours is a baseline to prevent burnout, and generally to have more diverse life where you have time for family, leisure, or even coding your pet project that you don't hate, but it doesn't put any money in your pocket (yet :P)
Some people are dyed-in-the-wool programmers, and doing this is fun for us. It's eustress, not work, like lifting weights. Those other folks watching the clock are doing a job.
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.
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.
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:
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).
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.
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.
When push comes to shove, go down to the most the basic of debugger tools. Print output to a tracing/console. I have had to resort to some version of temporary print statements in my code to get thru with debugging. And along the way have found many situations where those print statements or the logging/tracing equivalents introduced changes that altered the program's behavior.
I remember finding a situation where output of console.log would not match reality when debugging using chrome's debugger while working on a react app in 2019. Had to resort to making a copy of the variables to get console.log working in that situation.
When it comes to web deveopment, like others have said, it is easy to debug modern web apps with the help of source maps. We have been doing some version of that for a long time now. I remember using source maps with codeview back in the late 80s/early 90s.
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.
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?
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.
personally i rely on barking (printf) no matter the environment. in fact, my personal unpopular opinion is that people rely way too much on IDEs for debugging and that barking can solve 95% of bugs. (race conditions are more difficult, of course)
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.
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.)
It can. I love using debugging problems as an interview question.
Give the candidate some simple code (~200-300 lines is probably about right) with a handful of failing unit tests. Sit them down, walk them through running the test suite and ask them to find and fix as many bugs as they can in 30 minutes.
It pays to make the first bug trivial (like, a typo or something) and make the subsequent bugs increasingly subtle. You learn an awful lot about a candidate by watching their process.
The hard thing with this sort of question is calibration. Candidates will be able to debug way less code than you think in 30 minutes. It helps to run the code past a few coworkers before giving it to candidates to figure out if its too hard a test.
The surprising thing about this test is that it seems to be really highly correlated with senior engineers. Senior engineers often don't do as well as smart grads at coding problems because we often don't write that much code any more. But senior engineers seem to do waay better than juniors at debugging problems. If I could only get a candidate to do one programming problem, I'd get them to debug code. I think you get a massive amount of signal about whether you'd want to hire someone out of a debugging challenge.
Debugging works extremely well during an interview because:
1. Your evaluation can be interactive: you're watching them step through, can stop and ask questions about their thought process, etc. If it's a theoretical problem (ie: not on a live computer) you can even re-calibrate on-the-fly if they're really quick (maybe a lucky guess) at narrowing down the issue, or just asking "what if this happened instead, what would you do?"
2. Grading the candidate is subjective, just like the rest of the interview process.
The OP was talking in the context of college-style evaluation. I don't think you can apply either of these things to grading someone in a course. (1) doesn't scale, and (2) isn't a fair (or unbiased) way to evaluate students.
I’ve done “prac tests” before when I was studying CS. The test happened in a computer lab. We were given some specs and had to submit programs which implemented the specs. (The specs were written in a way that grading could happen automatically).
Just do the same thing, except the student is given some code with some failing tests. Their grade is determined by how many of the bugs they can fix within the time allotted.
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.
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.
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.
This is exactly my point. It's even worse in a "school test" situation, because who knows what contrived scenario the instructor has invented depending on what their focus is (eg: DNS vs physical net vs routing vs apache config).
Maybe there are multiple DNS servers for the zone that are returning different IPs, maybe one or both of them is even in split-zone configuration so it returns a different IP depending on if you're internal or external. Maybe the client has manual DNS configured or a hosts entry that's wrong.
Each of these problems would have several more layers of troubleshooting steps and branching, and it's not even a complete list -- and this is only if the problem is DNS-centric! There's hundreds of other branches for each of the other problem categories.
I mean if it is a test you obviously test things that you tought them first, or not?
Of course in reality there can be more, weirder things — especially if you are coming into an unknown network. But we are talking about an educational context here, would not make a lot of sense to let your students run into new unknown issues on a test unless your goal is not to educate.
One of the problems with debugging is that everyone seems to approach it differently. With some of the approaches working better than others in some situations. Which is why a group debugging session works great when you have a tricky problem that is not getting solved by one person.
We can definitely test for basic debugging and troubleshooting skills. But I havent found a way to consistently evaluate people who are capable of identifying and finding solutions to complex problems. These days a lot of these come down to framework level experience. With the proliferation of frameworks and tools used in modern apps, it is impossible to find someone who can solve problems involving all of them. So in a big team you want a variety of such experiences to cover a wider base.
Having said that, I have been in many situations where i have had to join a debugging session involving technologies or programming languages where i have had zero prior knowledge and have moved things towards a solution by asking what at times seems like basic queries to help others come up with the solution.
Debugging is difficult to test in a university/exam setting, but can be tested in an observational sense. Stripe does it in one of the on-site interviews.
A compounding factor is that it's much harder to debug code you're not at least reasonably familiar with.
Even if you can gain such intuition through looking at a piece of code, in a realistic scenario, more often than not you don't actually know in which file or method the bug is hiding. What you have is a code base and some externality that is wrong, the debugging process is essentially deepening your understanding of the relevant code (in relationship to what it should be doing) until you understand what is wrong.
Debugging isn't being able to use a debugger or a profiler or syscall tracing tool or whatever, sure they help but the critical skill is being able to quickly and accurately model the behavior of a system in your head, in combination with a tacit understanding of where bugs tend to occur.
I have been in enough debugging sessions to know that it is easy to weed out those who are bad from those who have the basics right. But trying to know if a candidate is good with advanced debugging is a futile exercise. You need to be in a few intense sessions with such people to know who are good/bad at these things.
I have only been able to figure this about people after working with them for 6-12 months. Which is why it helps keep references to such people and have them on your teams in future ;-)
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_1...
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.
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.
I think it depends on you personality whether you are able to hide your insecurities or not. I also do not know whether it is a good thing to hide them, because they can surface in other forms, like anger, bitterness, revenge, depression, and/or indifference.
It is probably better to deal with your insecurities, your deepest fears. With that respect, I think that the litanry against fear (from Dune by Frank Herbert) has some deep meaning. Making your fear larger, and than asking yourself what it would mean in the end, can help to overcome your fears.
Another things that I have discovered is that breathing techniques can help. Slow and deep breathing is a great technique for finding calmness. Many meditation techniques involves a focus on breathing. I think you don't need to sit with you eyes closed in a certain position and/or and think (or not) about certain things. It also works when you are sitting behind your desk or when you are walking around.
Great, thank you for the insightful response! I’ll think about it more. I’m reading the Dune right now coincidentally, the observation about fear is very interesting.
>> 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.
Ironically, the question for the PO is the better question.
Product/feature value usually spans a larger range of values than time to build it, so you don't need to estimate value as accurately for it to be a useful guide. It's also often easier to estimate because you wouldn't consider building it unless you have potential customers lined up.
And then if the PO says "building this feature would earn us back 2 developer-months in the first year alone" it's usually very easy for a developer to judge if building it fits into that profit window or not.
----
Of course, nobody does this in practise because people suck at decision-making. The next time someone asks you "how much will it cost?" try asking them "how much is it worth our organisation? What are we willing to pay?" and it will be clear they have done zero analysis on cost/benefit.
People don't know how to analyse -- or are uncomfortable with analysing -- these things so they are looking to be guided by their emotional response to information.
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_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’.
>> A lot of this stems from the accepted norm that an estimate is a single value.
If we want to estimate accurately, it is necessary to break work down into smaller pieces. However, we can only estimate the items that we can identify at the time of estimation (I.e., we know that we need to do A,B and C but discover that D,E and F are needed as well).
The other factor is combinatorial explosion: we'll do A,B or C and this impacts what we do next. This graph can become enormous when attempting to construct up-front.
I agree that having a probability distribution for each estimate is better than a single value. If you have two values, this is a uniform distribution. It is also possible to do a normal distribution, triangular, truncated normal, etc. However, it isn't clear to me that increased sophistication leads to better outcomes.
Completely agree. The overcorrection applies in both directions.
The two value (estimate and confidence) is just a simple approach that is rather intuitive to interpret directly. As you note, diving into 3 point estimates gives to ability to extract beta distribution or other weightings that may or may not be suitable for the given domain.
Complete top down planning for any work that involves discovery is useless, at best. That doesn't mean no planning is better.
(Source: have experienced and been actively involved in both sides of that overcorrection.)
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.
"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.
> 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.
this so much. we have these stupid weekly meetings where this one guy just asks us a dozen question. and then we try our best to answer them on the spot with incomplete information. just post that shit in the chatroom and we'll answer with a thought out answer when we can.
standups are pointless status updates where no one listens to each other.
even doc reviews, which can be useful, often get fucked because the clever folks with things to say can't leave them as comments on the doc so the owner had time to review and think about them.
save meetings for things that require actual discussion, not questions or status updates
> 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.
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.
You are right that people won't pay attention to anything that isn't already of interest to them, but the medium of exchange makes no difference there.
In fact, there was once advocacy towards a style of meeting (oft called a "standup") where you explicitly called upon participants to give their status update because it was recognized that they wouldn't be paying attention and needed prompting to snap them back, although this has largely fallen out of favour as we realized that only kept their attention for the length of their update and didn't achieve the desired effect.
I've not had this for the last 10 years, so it can definitely be removed.
Obviously everybody is welcome to bring up whatever is interesting nd worth discussing, and that's what we do in my current and previous workplaces. But there should not be a requirement that everybody has to bring up sth, which would lead to the described issues..
> I've not had this for the last 10 years, so it can definitely be removed.
You’ve sat in regularly scheduled silence for the past 10 years and people still show up?
> Obviously everybody is welcome to bring up whatever is interesting nd worth discussing
But logically they would have already said it when it first became interesting, unless they felt pressure to pad a scheduled meeting with content, withholding information from the group until the meeting takes place. So, again, what’s the point of sitting in silence or purposefully denying the team information to satisfy the social pressure?
I don't understand what you are talking about. Obviously we don't sit in silence. Some things are just easier to discuss in a meeting than over 100 Slack messages. Those things we discuss in meetings.
Right. Like I said in the first comment, after you know there is a problem, calling a meeting to discuss that problem can be quite fruitful. You only need 1 Slack message to say “Hey guys, this isn’t going smoothly. Can we talk?”
The original context was about meetings intended to let others know there is a problem. A time to allow you to say things aren’t going smoothly. But why would you wait for a meeting to let others know there is a problem?
The only reason is because you feel pressure to ensure the meeting isn’t silence. Otherwise you would have logically made it known long before. What is really gained in withholding information from the team?
Not all issues are urgent. Most issues I encounter in my job are not urgent. Sometimes it's not even issues, perhaps just a random but interesting observation. It can be less distracting to the team to bring them up next time you have a regular team meeting scheduled, instead of blasting it into a slack channel or even calling a specific meeting. That's what sync ups are good for.
I agree there is little urgency. After all, if there were, the withholding of information would be devastating, not just annoying.
But you're right that having a low priority Slack channel that you can casually look at when you're at a natural stopping point is way less disrupting than having to drop everything you are doing because the clock says it is meeting time.
I wonder sometimes if people who get engrossed into this meeting culture have just never experienced better? Anything can seem like a good idea if it is all you know.
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.
"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.
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.
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.
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.
> 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.
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.
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.
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.
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.
And the majority of doctors, nurses and lab technicians work in hospitals, yet they don't all have the same job.
IT the job is nowadays mostly understood to be about installing printers and setting up computers. Software Engineer/Developer/Programmer builds software. Sysadmins manage servers. SREs develop and operate production infrastructure. Nobody knows what DevOps is.
Outside of Germany and its neighbors, nobody thinks these four jobs are the same job.
The dictionary definition of information technology (IT) almost exactly describes software engineering. So what is wrong with calling it "working in IT"?
For reference, Merriam-Webster defines IT as follows:
> the technology involving the development, maintenance, and use of computer systems, software, and networks for the processing and distribution of data
I think the confusion is "IT" the sector and IT the job. Yes, computers are information technology, but saying SWEs work in IT is kind of like saying a pharmacist "works in medicine". Being "in IT" typically means you set up office computers.
Not sure what your native language is (for Spanish speakers "working on", "working in", "working at" could be a reasonable distinctions) but think the punchline is that it's software "development" or "engineering" and not simply "IT". Although some may argue they all fall under the same general label as being IT (i'm not opinionated)
20 years later I still cringe a bit at the term "software engineer", but that's a different debate. Given how much work nowadays is about technology, calling 30% of the working population "IT guys" is perhaps not super specific anymore, so language evolved.
Nowadays, "IT" anywhere outside of Europe refers to basically an operational or support role. (I think Europe being the odd one out is an effect of most European business leaders still thinking computers are a fad that'll go away eventually.)
> 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
I did not perceive it as a self improvement piece that much but you are absolutely spot on: the professional responsibilities are unevenly distributed.
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?
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.
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.
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.
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.
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.
the "what do you want to be when you grow up" question kids get asked usually involves something involving labor (unless astronauts, firefighters, teachers, and police work for free!)
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).
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.
> 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.
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.
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.
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.
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.
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.
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.
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?"
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.
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.
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.
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…
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.
> 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.
In healthcare, yes, and everybody understands that.
In software engineering, not so much. I think the OP illustrates that fairly well. What he’s describing is a janitorial job, but he clearly thinks he’s a physician, and he has written a blog post titled “What it’s actually like to practice medicine”.
> 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.
> 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). 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.
> 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.
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.
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.
>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.
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?
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.
Im not working a second im not being paid - its fun, sure, but its not that fun that i'll work for free.
> 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.