I would encourage anybody interested in a professional career (in anything) to zoom out and keep in mind that almost every profession is ultimately about providing service.
You will primarily work with (and for) other human beings, inside your organization and outside.
The measure of your success is often perceptive, coming from a boss, a coworker, or a client, and it may not directly correlate with your perception of what you may or may not have personally invested into the solution.
Software engineering is philosophically no different than plumbing -- sometimes the job is designing and implementing a plumbing system in a new building, other times it's diagnosing the source of a leak and fixing it, many times it's clearing literal feces from a pipe. Your value is not just extracting those turds, it's often being calm, competent, compassionate, timely and communicative while doing so. It comes from perseverance for solving the problem to the customer's satisfaction. It also comes from defusing situations with angry / incompetent clients, disaster projects, and resolving chaotic situations. Your role is to help reduce friction and solve problems for a person or organization in need.
That you're writing software is purely coincidental; it's but one of many deliverables you provide throughout the course of your career. The rest are "soft" -- insight, support, quality, reliability, trust, consistency, charisma, general likeability as a human being, etc.
If you're doing this for a job, you're going to have to deal with a lot of people, a lot of arbitrary constraints, a lot of bullshit, and a lot of bureaucracy that have nothing to do with writing software.
The same argument could be made for law, medicine, engineering, hospitality, cooking, fashion design, driving a taxi, street performing, drug dealing, sex work, you name it.
That's just the reality of work! If you're more interested in making art, do that instead (or both at the same time), but try to understand that there's a marked difference, and they serve separate, necessary roles in life :)
What a great comment. Thanks for writing this out.
One more thing to mention here is that Software Engineers are paid more because the industry is able to scale well to individual engineers outputs.
One thing where Software Engineers differ from a lot of others is asymmetric input and output. A single change in production can save millions of dollars easily. This is possible but difficult to do in other engineering fields like Construction, Hardware etc.
> A single change in production can save millions of dollars easily.
And a single change can also lose a lot of money (maybe even millions in some cases). I don't know about other fields, but I feel like this fact heavily increases the stress factor in some positions, especially if one or few people have all the repsonsibility. (Which we can say is a management problem, but still is a fact of life for many people)
> I would encourage anybody interested in a professional career (in anything) to zoom out and keep in mind that almost every profession is ultimately about providing service.
> You will primarily work with (and for) other human beings, inside your organization and outside.
I used to be an engineer who always new technology and push a fancy solution to an invisible problem—just for the sake of it. Now I listen more to people on my team, carefully consider pros and cons before adopting a solution. That's the biggest lesson I've learned.
Well said. It took me an embarrassingly long time to realize this.
Part of the problem is that many software engineers never get to talk to the actual users who are benefiting from their work. Or if they do, it is only when they complain about bugs or missing features.
Now that I'm a consultant, talking directly with customers, I can see the excitement in their eyes when I solve a problem for them. It's usually a trivial piece of code that any junior engineer could do, but it solves a real problem that they've struggled with.
This is true most of the time, but assuming your boss and coworkers are doing their jobs well (which is why it's not true most of the time) people will regularly communicate the things that are helping or hindering in their work.
Of course, you might find that your perfectly clean code isn't as helpful as you expected, depending on what you see as "clean." You'll learn that people care about how quickly they can understand and use your code, and whether they can make changes without worrying about breaking things. That's all they care about, and that's what "clean" is supposed to serve and accomplish.
If nobody gives a fuck about clean code in your org then you really need to find a new org. Perfect need not be the enemy of good, but if nobody cares at all then the problem will just get worse over time. Get out while you can and surround yourself with people and an org that take pride in their work.
Completely agree. It's the equivalent to keeping a tidy workspace with others in mind. Teams should spend time narrowing down coding styles, naming conventions, and general rules together over time, and stick to them.
As new people are onboarded, stick with those rules but have periodic moments where you solicit feedback from your team on the approach and make changes.
It really does help to have a team agreeing on these things collaboratively, and ideally having a more senior person enforcing it during code review where it's reasonable.
It's basically like a construction site - plenty of low rent projects are done in a totally disorganized "get 'er done" way. You won't see that as much for a high value construction site with top tier vendors and workers who value their craft.
> for a high value construction site with top tier vendors and workers who value their craft.
Is it really that, or are there just so many parties involved, that a heavy bureaucracy/coordination layer is required to keep the project from collapsing on itself, and this happens to manifest as everything looking neatly organized and structured?
This and construction is governed heavily by codes (in the US, at least). This constrains how much freedom builders have to design any-which-way they want.
But to the OPs point, there is a stark difference in the quality of work between tradespeople who respect their craft and those who look at it as merely a means to a paycheck.
There’s some related thoughts on safety practices that would be readily apparent to someone on a job site that apply to software as well. In my personal experience, people who don’t take pride in their work are the same ones that end up creating unsafe situations. The software parallels are easy to imagine.
> It's basically like a construction site - plenty of low rent projects are done in a totally disorganized "get 'er done" way. You won't see that as much for a high value construction site with top tier vendors and workers who value their craft.
There is often no better feeling of leaving a job where spaghetti code is a constant problem. I've worked on projects where co-workers took numerous short cuts that I'd regularly have to fix months later after they ditched their role. There is no real way to fix the problems of that kind because companies that emphasize proper testing and clean code simply don't weather tight deadlines and cost cutting that the rest of the industry imposes on everything, that's why there is often no better feeling of leaving a job where spaghetti code is a constant problem, :P
I agree with this. The metaphor I use is restaurant kitchens. Some kitchens are permanently greasy and look like a bomb went off. The best 5-star kitchens are a whirlwind of constant cleaning and mise en place.
"Clean code" is useless when it's an artistic aesthetic, but operationalizing the sense of "everything has a place, clean up as you go" has concrete value. You can spot teams that DGAF vs. teams that treat their responsibilities like a 5-star kitchen. In both cases, it's "just" a job, but that doesn't equate to carelessness.
Like with many of the examples in the replies - they may not care about how clean your code is, but they sure as hell care (and notice) if they're constantly having to untangle someones shitty code after it broke production again.
It's about where you are at relative to the median in the group, typically, not about any absolute standard.
What exist is code that can be maintained, and code that just cannot (in practical time). There is no sharp cut, is a continuum. But if nobody cares, at some point it grinds to a halt.
Software has been around long enough that many companies have been burned by bad code and so they are willing to give training and time to making it better. While there are trade offs, spending several years of no features while engineering rewrites the whole thing isn't acceptable.
Extensibility is the term that speaks to this situation. Extensible code, updated by skilled developers, will allow for radical business logic changes without sacrificing the quality of the code over time.
It's like a skyscraper. The critical structural stuff is fixed but the architects and engineers try to minimize those pieces and create flexible spaces that can either be high density cubicles, enclosed offices, a cafe, etc...
Eventually it's true that you have to tear it all down and there's nothing wrong with that - a good developer will know when that makes sense based on the needs of the stakeholders and make that recommendation.
I like it, but I think how easy it is to replace is more important than how easy it is to extend. Otherwise it might end like those massive class hierarchies instead of a function.
For me, pure functions and enforced types do the trick.
Not all code is created equally, not all code needs to be clean or have a lot of time spent on it. Many times those who "care" about clean code have difficulty understand when it is, and isn't appropriate.
> Of course, you might find that your perfectly clean code isn't as helpful as you expected, depending on what you see as "clean."
To add to this, people will have different opinions on what is "clean". In fact you will have different opinions on what is "clean"!
I've lost count of the times I've written some code, only to come back the next day and re-write it into a "cleaner" version.
Like writing an essay, it takes time and iteration, and sometimes there just isn't a stable solution. This has somewhat helped me in just writing the damn code (but my ADHD brain still habitually reaches for "perfection" over "get it done")
I remember a time in my career when I looked at some code and I was truly impressed by whoever had written it. It was different from the code I was used to finding in the company's codebase. The intent was clear, it was efficient, etc. I looked into the source code history to see who wrote it. I was surprised to find that I had written it, but I'd entirely forgotten writing it. I got a good laugh out of that... but I was mildly disappointed that I couldn't praise someone else.
Of course this is the exception rather than the rule. I've done a lot of revision on my code. If you don't look back on your code and think of ways it can improve then there's a good chance you're not learning.
I love these rare moments when I think of solving some problem, figure out what I need to do and where, proceed to get started - only to notice I have already done this exactly the way I had planned, but forgot about it.
Talking with team members to get everybody to agree on what the style is can fix this.
Talking seems to not happen, in my recent work experiences - instead it's a pain to talk to people because you have to do fucking zoom meetings and it has to be scheduled. Or the company actively discourages the team from setting their own technical goals of quality in the name of some ridiculous abstracted version of addressing customer interests. It's out of balance - customer interests are left on the ground while quality is also left on the ground.
Having a tight team is what we should be focusing on! ChatGPT is going to eat so many of our jobs. We should be focusing on being excellent humans.
I was warned about that ego driven development while I was at school by the teachers. Apparently it's been formalized as gospel ... people lie to themselves calling it clean. Basking under the warm smile of Uncle Bob. Creep.
The real problem is that "clean code" is completely arbitrary and if you ask 10 software engineers you'll get at least 5 different answers because this really boils down to preferences.
> The real problem is that "clean code" is completely arbitrary and if you ask 10 software engineers you'll get at least 5 different answers because this really boils down to preferences.
I disagree. I'll take a bet that given 10 experienced software engineers (we can define what this means -- title, years of experience, familiarity with language idioms, etc.) they'll mostly agree on samples A, B, C, ... of code if it's "clean" or not.
Code doesn't have to follow my preferred design pattern to be clean. The bar is don't be shitty, and I'll know shitty code when I see it[1].
I really doubt there is any such consensus. Some people really care about superficial code quality (good variable names; short functions; consistent formatting and documentation; compiles without warnings). Other programmers care mostly about architectural quality (shallow call stacks; correct data structures; few dependencies and little scaffolding).
As stated in the previous comment, if you give code from group A to group B, they will tell you “I would prefer this and that, but still seems clean to me”
I don't agree. I know what the previous comment said.
Modern C++ codebases that make extensive use of templates, inheritance, exceptions, type coercion, closures are considered clean by many because the code looks nice. But code like that can be a nightmare to work with, because of long compile times, spooky action at a distance, etc.
Writing good code requires good taste. Taste is subjective and cannot be easily codified. That doesn't make it arbitrary. Ask ten people about their favorite movie and they'll name ten different films, but I'd wager no one will say "Gigli".
I agree. The hardest thing I had to learn as a professional programmer: There are multiple styles of good taste. You need to be tolerant. When I look at some GitHub code reviews, I cringe at the number of pure aesthetic (aka low value) issues that people endlessly nitpick about. It is discouraging towards contributors.
I work on a team now where the three main contributors (including myself) all have _reasonably_ different programming styles (naming, whitespace, structure, const/immutable, algos). Having read enough code from the other two: I am confident they are good programmers, but their style is different from mine. Still, we try very hard to accommodate each other's style. When we make changes, we try to stay with the current style in the class / method. It has been a real learning experience for me.
This would be a hard no from me. I cannot stand having to switch style when working on the same codebase or even in the same company.
codestyle enforcement via pre-commit hooks or CI build failure is the way to go. Trying to adpat to codestyle is a distraction. All distractions should be removed when coding.
That's a bad analogy. People will certainly have different favorite movies, but they can also come to agreements on what's a "good" movie. There are a bunch of movies that I think are "good" movies in a more objective sense, but aren't my favorite things to watch. There are movies that I thought were excellent, but I have no desire to see again.
I agree with you. From experience, this pain is a red herring, it’s symptomatic of a specific kind of change: new features or bug fixes that require tight coupling of previously-authored-as-decoupled things. Clean code, architecture, whatever - it always falls over in the specific transition from decoupled-to-coupled.
Why do programmers hate making those changes? They always require tossing out a lot of existing code. So I guess I could say the antagonist is inertia. Certainly has been my experience interfacing with vendors and BigCo developers. If you have the ability to suppress this feeling, to delete stuff that works but is not correctly coupled to the new problem, you will thrive regardless of the architecture.
I disagree. While one can argue pointlessly over which code is the cleanest, it's very obvious when the code has a complete absence of it. I think of some 3000 line classes that I have met and done battle with.
The sibling comment that talks about "how quickly they can understand and use your code, and whether they can make changes without worrying about breaking things" is on the right track.
The heart of your comment is true, but good organizations establish a set of standards for how they define clean code. At that point, it's no longer arbitrary.
But still, we should strive for writing the best "clean code" that we set out to write. So "clean code" here is subjective and bound to the individual. Normally, business and absurd deadlines force us to lessen that principle—that's what I call "ugly code".
> whether they can make changes without worrying about breaking things
In my experience no coding standards or cleanliness can prevent this. The only sure way is testing on commit/PR.
EDIT: A common failure mode I've noticed is that people only test the functionality they've added and not other parts of the system that may be affected.
> A common failure mode I've noticed is that people only test the functionality they've added and not other parts of the system that may be affected.
This failure mode often comes from parts of the system being coupled when they shouldn't be, or it's not obvious that they are.
Have you ever had a change to a logging statement break cause some other code to stop functioning? I have. And I was thoroughly disappointed by the person who made a logging statement have any effect outside of logging.
Clean code needs to adhere to principles such as the Principle of Least Astonishment[0], otherwise code is bound to break when other people modify it.
About "Principle of Least Astonishment": In theory, it is cool. In practice, it is often used by gate keepers to shutdown newbies. After seeing that behaviour too many times, I stopped using the term.
A nicer way to say it (from pair programming ethos): If someone asks you a question to clarify some code, then it needs a comment (or a re-write/re-factor). Note that I didn't say anything about the experience level of the asker.
One more thing: I've met (multiple) people who are firmly in the "Convention over configuration" camp and the "Principle of Least Astonishment" camp and cannot understand how new joiners are continuously surprised by this or that convention.
Coding standards an cleanliness are at the wrong level.
What makes it easy to make changes, add features, find bugs, etc. is good design.
Testing can help find problems, sure, but you can't test in quality (you can only, to a degree, test in robustness).
The difference between a decent design and a mess is mostly what happens when your "simple, local fix" causes unexpected tests to fail. If your first reaction is "damn, guess we can't do that" three is a good chance you have a mess on your hands.
Clean code (yes some of this is just taste) is mostly a symptom that people have been thinking about this stuff, not a guarantee.
There is a corollary though, which is difficult. Quality of design and techniques used mostly put an upper bound on the complexity the system can have before it becomes unmanageable. If it grows long enough though, it will get there.
> In my experience no coding standards or cleanliness can prevent this. The only sure way is testing on commit/PR.
I think that's an issue with how people define "clean." It isn't just about surface aesthetics. Think of a cooking appliance that looks "clean" in its design, that might win a designy design award, but accumulates gunk in hard-to-reach crevices because it was only designed to look clean, not designed to be kept actually clean.
Fair enough - it may be that I've never experienced "real" clean code. But I've worked with many good engineers and seen this problem repeatedly. However, no matter how unclean the code is a rigorous test suite will find many regressions.
No, they don't. But that's the problem, you can't force all developers to consider these issues and adhere to coding standards. Sure, you can do reviews and then make them do that, but if they have to pass a suite of tests before it even gets to review then that's going to save everyone's time and train them to do it right.
Sometimes what some people think of as clean is really more "optimized for the current state or the project." that seems fine, until next month the new feature requires that "clean" code be ripped apart because it encoded too much of the current program state as assumptions in how it worked.
Be careful not to conflate clean code with premature optimization. Clean code is easy to read and follow and works in obvious ways, it isn't necessarily the fastest or most efficient code and nor does it mean it has to use deeply nested knowledge of how the system works to function in ways that are non obvious to new readers.
I wish people would understand this better. "Clean code" doesn't exist. You should define (and automate) quality gates for your code base as a regular team excercise. I've seen enough teams not even having a common agreement on what a code review is and then trying to do them. When regularly wondering on a code review if change X meets the subjective taste of reviewer Y or even getting into fights you know somewhere something went wrong in team culture.
Tests matter, but elegance and simplicity matter, too. Tony Hoare said, "There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it." All code needs module-level or API-level acceptance tests so that anyone can change it and deploy it with confidence, but well-written code needs fewer low-level tests of implementation details.
I agree with what you wrote, but I've worked with people who balk at even automatic gates. "Pass pep-8, as enforced by pycodestyle" was practically too much for one coworker I had, who, when it was pointed out in review that "the automated CI step was failing, can you please make it green?", would fix like one violation, then just ping their reviewer? And around the mulberry bush we went. Various odd arguments like, "well, my IDE has pycodestyle built in, and it's fine" (it seemed like his IDE had its own, separate, lenient config? … but like, nobody cares about your IDE…?) etc.
At $different_employ, there was lots of thrashing of teeth pertaining to `yarn audit` running against the codebase, and failing people's builds. Some people fought tooth and nail to get it to not fail the build, because they didn't like that their new feature, which didn't introduce any vulns. per se, was failed. Later, other people did much gnashing and wailing over being "confused" because the yarn audit step was red-X, and they were confused as to why it was breaking on their feature branch. It wasn't: it was failing, but marked to be ignored, so the build continued. Other, required steps, were failing. (And were also marked with red Xs.) This was "all too confusing", and it was petitioned for yarn audit's CI step to just "fail" with a green checkmark. You can imagine, I'm sure, how many vulns. were addressed after that point.
I've also worked with devs who are just amazing, and aside from being brilliant in how they architect their code/systems in the first place, … they have a definite tendency to view lint errors as just "oh, oops, silly me fixed" and just Get It Done.
QC is hard.
(Regarding our audit step, too: we also had an ignore list. You could just add the vuln. to the ignore list, and that would technically placate CI. Obviously not the best … but CI didn't demand that you fix whatever the issue was.)
> Some people fought tooth and nail to get it to not fail the build, because they didn't like that their new feature, which didn't introduce any vulns. per se, was failed.
Well, here is the problem this introduces. Who is supposed to fix this and which PM's bucket of time does it come out of? This implementation just makes it seem like the answer is "whichever team is unlucky enough to make a PR when it is discovered." The perverse incentives of that are enormous.
> You can imagine, I'm sure, how many vulns. were addressed after that point.
This tells me that the responsibility isn't specifically assigned. This seems to be the broader issue, with the audit in the pipeline a managerial attempt to get vulns somehow fixed without doing the work to figure out how they will be fixed and who will do the work.
Someone actually needs to be responsible for it and be given time to do the changes. It seems like this was not done.
The team of eng responsible for the code against which a vuln. has been detected, would be my answer.
> This tells me that the responsibility isn't specifically assigned.
Well, no, for the very reason you've highlighted: PMs will be damned to have that time come out of their bucket. That is a problem, and I rather doubt this subthread'll solve the idiocy that is PMs.
Nonetheless, if we accept that vulns. are something the industry should pay attention to, i.e., that "keep stuff using secure versions of dependencies" is actually a best practice the industry should adhere to, someone has to triage the audit report, and then someone yet has to do the deed of correcting it.
Yet both your comment & a sibling have advocated the position of "no, drown the test result, don't block builds". If builds aren't blocked, there is zero impetus towards ever fixing vulns., so they don't get fixed, ever. You cannot, IMO, ignore human nature when setting up these kinds of QC checks in CI: if you make them optional they're as good as dead, cause people are lazy.
You're missing the larger point of my comment, too: there is no sensible setting for that CI step. Say I don't care about what the CI step does, say I don't attempt to take a position in this idiotic debate. I can't: literally any configuration boils down to one of two cases: a.) we're flagging the problem, and devs don't like that and whine and complain or b.) we're ignoring the problem, and security people claim they don't like that, and whine and complain.
I think you're also forgetting how software is actually developed in the wild by many companies: this example, like so many, use a "monorepo". I don't like this (I'd argue for single-purpose repos, and it'd be obvious who the owner of a vuln. is, since the whole repo is only owned by one team.) but nonetheless I'm pretty consistently outvoted on this point, and the majority of firms out there seem to go the monorepo route. So, in a monorepo, "who" is responsible for a vuln. against a third-party dependency? (It can be figured out, but the answer is certainly not as straight-forward anymore!)
(Single-purpose repos aren't without issue here either: often I find in that case that establishing these sorts of "common" CI steps to be hugely problematic: you sort of have to c/p a lot of code between repos, keeping that step's code updated is then a PITA, and many CI systems lack good support for "use this common step, perhaps not even located in this repo".)
To me it seems like the better way to run such audit code is against the main branch periodically, and it's someone's job to triage failures at high priority. Attaching it to unrelated changes is half the problem. But it's not something that fits into the common CI workflow which assumes breakage comes from code changes, not updates in an external vulnerability database.
> Some people fought tooth and nail to get it to not fail the build, because they didn't like that their new feature, which didn't introduce any vulns. per se, was failed.
Well... yeah? They're working on a feature and get arbitrarily told that they're not allowed to merge the feature until they go fix some completely unrelated vulnerability problem. How is that reasonable?
Anything that can be automated for QC, should be. But if you want to completely eliminate subjectivity, you have to stop working with SW.
There is nothing an will never be, something that can test if code is really easy to understand. Had you such tool, the tool will be able to code by itself.
> This is true most of the time, but assuming your boss and coworkers are doing their jobs well (which is why it's not true most of the time) people will regularly communicate the things that are helping or hindering in their work.
Code reviews seem to be the norm now. I'm struggling to see how that aligns with everybody not giving a fuck about code quality.
Maybe it was true. 40 years ago, we noticed code gets read many more times than it is written. It took us a long while to do something about it, but now insisting programmers produce readable code is easy to read where the industry is at.
It's not just "the industry" either. Try submitting a bad piece of code to the Linux kernel and see how many fucks they give you. It's the same for an open source project that does code reviews.
I think the problem is that, while most people agree that badly factored code that drags down productivity is a problem, people can't agree on how to make it better. So, discussions about code quality get mired in subjectivity, often people can't agree and if anything changes at all, you agree to some half-baked compromise that doesn't really address any of the issues.
I don't think how you can avoid that unless you find people that have similar ideas to you about how to write code.
having done this, I generally think my old code is fine.
When people say things like I this I always point out that this may be true for the first 2-5 years of you developing but if it's true 15 years in you're not actually improving you're just being mercurial.
At some point your growth as a developer moves outside of code and you recognize that there's beautiful code, devilish code, and then a huge grey area where things are just fine even if they aren't how you would have personally implemented them.
Having been in the industry for 10 years, I would agree that after a certain point, your personal opinions about code style tend to change less and become more consistent, but I still run into enough other people that also have a lot of experience, yet seem to have entirely different views.
Out of interest, what kinds of things would you consider "beautiful" or "devilish"?
I read through the CLANG code back in the early days of its existence and found it to be quite elegant in its structure.
devilish, I once came across where someone had accidentally written a FSM that used http redirects as the transitions between nodes. All to animate a progress bar for a job queue. It was so ridiculous it honestly took me longer than I care to admit to understand what I was seeing, who the hell expects to see that?
OTOH, we have a codebase at my current employer that opens up a TCP socket to a service and passes pipe delimited strings. And you know what? I give the thumbs up to that. Why? The service it's communicating with is an old C++ service that was written around the time that XML started coming onto the scene. That's how you did things back then and it works perfectly fine, albeit it's probably not the most familiar to younger developers.
Oh yes, I totally agree. Some things that I used to write, I would find insane now.
But it doesn't make the problem any less real. At my current job, I think our tests are really bad because they mostly don't test what really matters (also due to too many things being spread out across several services) and instead are coupled excessively to implementation details. That makes development slow and also means I can never be sure that my changes don't break something important.
I think the reality is you'll find that your universe of acceptable code is surrounded by a mess of infrastructure code that may or may not be clean because people don't have the ability to care about everything.
I'm talking about makefiles, build systems, shell scripts, packaging systems, installers and more.
I also think clean code is a luxury. The more your codebase is alive, the more likely that upgrades, features and fixes will go across the grain.
It's not like people are slobs, it's more like a living house where busy people come in out of the rain or snow, or put dishes in the sink for later, or occasionally spill a plate of food on the floor and have to clean it.
The ultimate proof of this is that the new AI models are VERY useful, but are stored as blob more similar to grey matter than structured modular code.
> Of course, you might find that your perfectly clean code isn't as helpful as you expected, depending on what you see as "clean."
Yes, readable code is the winner. Not "ultra compact" or "so elegant you can't understand it". I once refactored an elegantly written but heavily opinionated codebase for a large feature - and my goal was to hand it off without any downstream complaints - so I doubled the LoC and the team that received it was very happy with all the non-terse logic and detailed comments (good code is self-explanatory on how it works, but not often on why it's there)
One of the highlights of my long career was a new member of the team commenting to me that my code was "the most beautiful" that she'd ever seen. This was in reference to its clarity and actual physical layout. On the latter, I've always been compelled to make my code "look good" as I have much more difficulty working with things that are well laid out.
Yip. A good mechanic has all their tools organised/clean workshop. A shit mechanic has their tools spread all across the shed on the ground, spare parts and other rubbish littering across the ground, etc.
This is why I go out of my way to praise good work loudly and publicly when I see it.
If everyone merely accepts good work silently, but talks about bad work all the time, then political focus within the org will shift to bad teams and bad people. At the extremes I’ve seen this result in the worst people getting promoted to the highest positions because they were infamous. That’s the same as being famous.
Think about Trump: he got elected because nobody could shut up about him, so to a lot of voters didn’t know anything about any other candidate. They voted for the one they recognised.
“He may have his flaws, but he’s not that bad.” is something I’ve heard at work and in the public sphere.
You’re immune to this effect, you’re about to say?
> This is why I go out of my way to praise good work loudly and publicly when I see it.
This sounds true. Some people do the boring job of cleaning code and keeping the system reliable never got a praise. But some people, who never care about the quality of the system, fight the incidents and are called "hero".
The point is that most people are unable to remember good things that even very famous career people have done, despite this information being in the public record. It's just not covered, repeated, and as memorable as bad things that people have done.
You're focused on "Hillary bad!", not realising that that's the point I'm making. You can only remember bad things.
The exercise is to see if you can name good things. You can't, not because she's unadulterated pure evil, but because good things are not as memorable in general.
Try for a moment to rise above your primitive animal tribal instincts and think like an anthropologist.
Sorry to disappoint you but you're thinking like a Hillary fanboy, not an anthropologist. Democrats had better options available that'd have beaten Trump but people like you decided that Hillary was supposed to be the next president. Not many opponents would be so good at electing Trump.
I picked an example at random that I knew everyone would be familiar with. I have no skin in this game and who won or didn't win isn't the point. The point is the rules of the game.
I honestly wish there were some kind of rating system for employers where their code quality is rated on a scale of 0: spaghetti/lasagne precious mess written by a sacred primadonna chief engineer who must be deferred to reverently and takes a year or more to get the hang of, to 10: fully unit tested, integration and pre-prod environments, minimal pagers needed, competent QA, etc.
> You can forget that your boss will tell you: "Congratulations on writing this elegant and clean code, I am gonna give you a raise!". Quite the opposite, nobody cares about your clean code.
> Don't get me wrong, people will expect you to write good and clean code. Still, you will rarely get any praise for it. Except sometimes from your colleagues who will review your code.
If I can read your code, I don't give a frog's butt if it's up to the nose in the air crowd's standards. That just isn't what is important to a business that actually wants to survive and make money. It's crazy, those same blog heads are the ones who are always so quick to advocate for a "total rewrite" every 6 mos. They think all this nonsense makes them Pros.
Once a coworker spent 4 weeks arguing with me that his code was fine because "the test was green" before I touched it.
The test contained a "return true" before the actual test.
After writing countless emails to convince him to fix his code, and wondering why they wouldn't just fire him and save everyone else some time, the CTO announced that the guy was now promoted to team lead. :)
His code is not elegant, it barely works, requires constant full rewrites, is an endless source of segmentation faults, deadlocks, sleep() in the main thread and whatnot.
The only skill you need to get promoted is to laugh at the jokes of your boss and schedule meetings to demo your n-th rewrite of the same thing.
Estimates are important.
I've overheard a team lead claiming they are completely impossible.
How long does it take you to go to the store? Yes you might die in the process and take ∞ time, but one normally considers common inconveniences in this. A senior who can't estimate isn't a senior.
Of course at work I've heard a team lead say "I did my part, I have no idea when they will implement it" (not the same team lead I mentioned before).
> It will be almost impossible to disconnect from your job
I learnt that very early on. In my first full time job, my boss got mad at me for arriving at the office at 9:05, unacceptably late.
So precisely when my hours were done I'd stand up and leave.
> talk directly to them, be professional but not mean, and tell them what and how they can improve
And then get reported to HR… my advice is to be the 1st one to do the backstabbing and complain that it is impossible to work with them.
> Get used to being in meetings for hours
Working from home helps… one can cook and build lego during meetings.
Accurate estimates are impossible, but you can get better at them. Getting better at them mostly entails increasing your estimate to the point that it feels absurd, and then doubling it. To become a true expert, double it again. Another approach is to always bump it up a unit of time. So an hour becomes a day, a day a week, a week a month, a month a quarter, etc.
Really, you just have to be a pessimist. Instead of saying what people want to hear (it's simple and can be implemented quickly), you need to imagine the long-tail worst-case scenario where everything that can possibly go wrong goes wrong, then give that number. If people don't give you a somewhat incredulous look when you give an estimate, you probably were too optimistic. Just remind them that you're imagining a worst-case scenario and say that you hope to have it done sooner, but don't back down on your estimate.
Another thing to realize: at the business level, deadlines are often picked arbitrarily to create urgency. The specific date of the deadline is usually less important than just having some deadline, any deadline, to motivate everyone. Business people will pretend the deadline is Very Important, but it's all an act, more or less (arguably it's a necessary one). Remember this when giving your estimates.
[Managers] are like children. They want everything right now, and they want it their way. But the secret is to give them only what they need, not what they want. — Montgomery Scott
disagree, not all tasks can be estimated accurately depending on circumstances but this does not imply that it's impossible to estimate any task accurately.
No matter what the task is, things can go wrong that you didn’t anticipate.
Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before. Better make some coffee…
Some version of this can always happen, and as a task gets larger, it is almost guaranteed to happen multiple times in multiple variations. Since you don’t know what problems will arise, there is no way to know how long it will take you to fix them. You can stay up all night in order to pretend that your “quick and easy” estimate was accurate, but that only takes you so far.
> Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before.
yeah, and maybe I'll have a heart attack and die while going to take a piss but that doesn't imply it's impossible to accurately estimate that it's going to take 5 minutes for said piss.
What if, while cooking dinner, a meteor crashes in my kitchen and so my estimate of 30 minutes to cook dinner turns out to be incorrect? That _obviously_ means the conclusion is that it's impossible to accurately estimate how long it takes to cook that dish so we should never do so.
There has to be a name for the type of reply your post represents.
Software has an unusually fat long tail, to an even worse extent than real engineering. The probability of something unexpected popping up and inflating the time something takes by an order of magnitude is much, much higher than the likelihood of the same happening while cooking.
This ends up coupled with the fact that practitioners (of anything productive) tend to think in terms of 50-ish percentile estimates (i.e., there's a 50% chance this project is done in this amount of time), whereas business people care about 90th-99th percentile estimates. In software, the difference between between a 50th percentile estimate and 90th percentile estimate can be more than an order of magnitude in time spent.
I'm going to repeat what I said to another poster.
If your shit is breaking so often it's affecting your willingness to estimate, that's a you problem.
I'm driving to another state for the thanksgiving holidays, and I have an estimate for how long that will take. Is it possible when I walk out to my car that the battery died the night before? sure. Am I going to factor such an unlikely event into my estimate? no. Does that imply it's impossible for me to accurately estimate how long that trip is going to take? No it doesn't.
Only in software could someone be using a tool that constantly doesn't work and they never consider replacing it or fixing it. Imagine if a carpenter showed up to your house with a hammer whose handle fell off once or twice an hour but they expected you to pay them for the loss of productivity rather than purchasing a hammer whose handle doesn't fall off.
Not quite sure how you found your way onto a tech forum without any understanding of what software development entails, but unlike carpentry, where every time you want a new wall the carpenter needs to go through the same process to make the wall, or in cooking, where every time I want a roasted turkey the cook needs to cook a turkey, software almost never does the same thing twice. If you find yourself doing the same thing twice, that's a tool problem.
That produces a much fatter tail distribution, because you're doing someone that no one has ever done before, and thus no one knows exactly how long it's going to take.
odd, because my experience is that your CI/CD pipeline does the exact same thing repeatedly.
Perhaps the answer to your confusion about my experience is that I don't suffer tools that hamper my productivity.
Put it another way.
I ran a raiding guild for several years and about halfway through that stint I recruited a player that raised the bar for what I thought was possible. Perhaps you need your bar raised.
you mean the same world where no one has heart attacks and meteors have never hit houses?
Both have been documented to have happened, yet somehow you didn't seem to think that should be taken into account when considering estimates for cooking and pissing.
If your shit is breaking so often you're afraid to give an estimate, that's a you problem.
And yes, we had an internal team that w/i the last 6 months couldn't go a week without a deployment problem. Ask me why they no longer have that issue.
I think the reason that estimating is hard is that no one ever returns to their estimates and tries to fix the estimates. What usually happens is that people throw out a number, mismanagers think that number is negotiable, and whether the project's completion is in any way related to the estimate - the estimate is forgotten.
No one writes down "this is why I think the project will take X [time units]".
And no one goes back to that estimate and says "I left Y & Z out of that estimate, I better include that next time."
If you want estimates that have any relation to reality, your estimating process needs to have that sort of feedback.
> When people saying that estimating is hard...
I think they're referring to the sort where management negotiates the estimates, like you're haggling over something in the marketplace. If they have such a strong opinion about how long something should take, then asking you for estimates is setting you up for failure and blamestorming. "It’s one banana, Michael. What could it cost, $10?"
One of the most productive teams I worked on spent time at the end of an iteration to look back on our previous estimates and re-estimate them. We got much better at estimating the remaining work we had, and knowing whether we would hit deadlines or not.
In my experience writing out assumptions together with estimates tends to improve estimate accuracy a lot, by challenging the assumptions (and estimates) more at estimation time, and making it more visible when changes occur at implementation time that impact estimates.
As for negotiating estimates down, it is up to technical leadership to refuse to do that. Not easy, but doable.
Teams definitely refine and alter estimates as new knowledge of the problem space is discovered. It’s a management (and team) failure if this does occur.
Also, on the negotiation side of time it will take, I absolutely know for myself that I can code things fast and functional but a bit hacky, or beautiful and elegant and will take much longer.
The negotiation should be about when to do which.
At a higher level, you put your teams together within their temperaments in mind and match that to the work.
Some code will be a nexus of changes and interaction with other code (invest early), and some code will get written once and never seen again (go fast and forget).
One of the things that makes me so successful is that I always try and have a backup plan. "our goal is X, if we fail to meet that with approach Y then we'll use approach Z. Lets prepare for approach Z while we're also preparing for approach Y and evaluate and switch to approach Z as early as we possibly can. We still want approach Y so we'll continue working on it even if we start using approach Z to successfully launch".
The issue is that there's a fluidity in that thinking that many many MANY technical people either don't have or don't employ.
My favorite is being asked to estimate a bug fix before I've had any chance to analyze the issue.
It's like calling a mechanic over the phone and asking how much it will take to fix your car. The mechanic doesn't know if the engine just fell out of your Model T or if you're just trying to put the key in backwards. How about you bring it in first, then we'll look it over and go from there?
Sometimes you can ask some questions and get to, "Well it's probably X which would take Y but we'll need to see". Then they get Y stuck in their head and it turns out to be the one time out of twenty when the cause isn't actually X but something much more involved.
If you're being asked to estimate a task without insufficient information on what the task is, punt it back with 'More information needed, we'll look at it 3 weeks from now in the next sprint planning'.
Even on the store point: I might notice I’m low on fuel and fill up on the way. Easily turns a 15-minute errand into 20 minutes. Estimations in the context of a software project are similar to a promise that my trip to the store will only be 15 minutes which I’m held to even if I notice the low fuel gauge.
Shopping list is set and I should be in and out in 15 mins but it turns out there is no ketchup - so do I go to another store to get ketchup or mustard will do. Product owner my Girlfriend has to decide because she is doing the cooking and will present it to customers our guests, and she knows if they like mustard or not because she talks to them more often than I do.
But yeah going to another store might make dinner late and I cannot know this until I actually arrive at the store that there is no ketchup on the shelves.
Its a good metaphor also because if you have an appointment in 20min you would never go to the shop 15min before. Yet managers will force you still out and to the shop because of your time estimate.
Part of estimating is accounting for those contingencies. Given above, depending on my audience the above estimate will be either 30 minutes, or 15 minutes but could be as long as 30 depending on these factors. Part of estimating is accounting for the setbacks one can (reasonably) expect to see, to give the other party a timeframe within which they can be (reasonably) certain it will be done.
Of course there could be a fire on-route causing a jam that turns your 15 minute trip into 2 hours, but that's sufficiently unlikely it's probably not worth building into your estimate (but could be depending on the stakes involved! If someone is going to die you should probably factor this in so we can plan for that contingency). In that instance instead you need to communicate when it happens so that everyone involved can recalibrate.
Yeah, I had a PM who taught me to do this by doing it themself. My estimates are actually just doubled from how much I expect it to take when I know the design and can work with no distractions.
I’ve also worked with managers who “negotiate” as others sometimes describe. Of these I see good and bad. One who was aware of short- and long-term goals of our team and asked for estimates so they could decide what features we need to include; another who already promised the features and the deadline and is asking me to tell them that they did not overpromise despite my observations. (“I don’t believe I’ll be able to deliver those features by that date.”)
Others in between, including some who don’t like being told explicitly that I double the estimate. Worse still, the one who halves it as if to correct for some mistake.
I guess the moral is that developers aren’t the only critical party when it comes to communicating estimates. Managers do their own job; good, bad, or otherwise.
-------
> depending on my audience
Other than some managers I assume another developer or a good technical manager, and it’s a good approach. Sounds at least similar to explicitly stating that you doubled your “no distractions” estimate. Too bad it seems that an unfortunate lot of people work with the bad “negotiating” type who might even be so disrespectful as to correct their co-worker’s mistaken opinion -- which they asked for!
(Not to leave this as advice for the parent commenter. Just wrote some thoughts and figure I can share for anyone who might get value from them.)
From my experience, the two months of gathering requirements will be more valuable than developing something from zero requirements. Whatever you code with always be "wrong" because with zero requirements there is nothing to test against.
> I've been to the store before. A lot. I've never hooked in new library X to the codebase and implemented that new functionality.
Which is why you'll get better at estimating as you get more years of experience under your belt, and why estimating is something that seniors are better at than juniors.
Even after 20 years you may never have hooked in new library X, but I'd be willing to bet you've done something kind-of similar, and your estimate will be more accurate than a person with 1 year of experience and has never done anything remotely similar.
> Estimating things you've done a lot is trivial, and pointless.
Keep in mind you are not providing the estimate for the person who has done the task many times, you're providing the estimate to people who have never done it before. So for them, it absolutely is not trivial.
The issue everyone is skirting here about estimates is the unknowns. Letting management know what the unknowns are and how confident you are you can resolve them is just as helpful as providing an accurate hour estimate.
> The only skill you need to get promoted is to laugh at the jokes of your boss and schedule meetings to demo your n-th rewrite of the same thing.
As far as what the system actually tells you your job is: it's not to do good work, it's to be perceived as doing good work. This is an important distinction.
Notably, promotion in orgs makes demonstrating non-programming skills more important than anything else. Communicating a lot, and well, is likely a much faster route to a better title and better pay than digging into fiddly technical problems and saving the day that way.
You see a mediocre junior come in and carve a shockingly-fast path up the promotion ladder without ever getting good at programming—they're communicating better, and probably, especially, a lot more. The most-visible get promoted. Talk more, email more, message more, speak up in meetings more, call more meetings. Make yourself prominent in anything process- or architecture-related. It doesn't even need to be productive (most of that stuff's not).
The sad truth of how to get paid more in most orgs.
Yes! Figure out a way to make what you did visual, or nobody will care. Front end tasks are better to take than back end, because you don’t have to do extra work to produce a demo that’s not just text and numbers (and minor GUI changes still beat all but the most impressive benchmark graph, among many crowds). Factor the extra time-cost of this (sometimes more than the time it takes to do the actual work) into your estimates, when you can.
As a bonus, people who know nothing about programming, ux, or design, want to weigh in on UI. This provides a natural opportunity to have positive interactions with them, which is a very good thing. Ask if they want to have another meeting to go over their concerns one-on-one.
To be fair, the best team leads I have had were all far from the strongest developers on the team.
The best team leads job isn't to dev, it's to represent the teams interests to the larger organization, and I have known some people who have really gone to bat for us, while at the same time barely being able to code genuinely getting angry at CI for pointing out obvious problems with their code.
Dude I don’t know. Representing the team means understanding and making sure the architectural approach and interfaces/contracts with other teams are solid and will stand the test of time. This is certainly different from leetcode skills, but I’ve never seen a truly bad coder have any success at it.
If by team lead you mean manager, sure. If by team lead you mean tech lead, absolutely not. They should be one of the strongest developers on your team.
> How long does it take you to go to the store? Yes you might die in the process and take ∞ time, but one normally considers common inconveniences in this. A senior who can't estimate isn't a senior.
The problem tends to be that, a lot of the time, you aren't told what store nor what mode of transport you have. Or you're told both, but the store you were told to go to doesn't have what they want so you need to go to another store.
In my experience, being able to estimate is about both
- Being able to give an idea as to how long it will take given a list of assumptions, AND
- Being able to highlight what the risks are that can cause it to take longer, and how much longer. Those risks sometimes include the fact that your assumptions were wrong in some way; and sometimes include lots of other things (dependencies, etc)
> His code is not elegant, it barely works, requires constant full rewrites, is an endless source of segmentation faults, deadlocks, sleep() in the main thread and whatnot.
A lot of negative points, indeed, but the first priority is to ship new functionalities. If he was the only one focused on shipping, while you others loved to get lost in useless architectural debates, he was the best candidate to team leader.
Corollary 1: clean, maintainable code is only important when you have customers expecting maintenance.
Corollary 2: in the Real World (tm), the alternative to technical debt is getting out of business.
> A lot of negative points, indeed, but the first priority is to ship new functionalities. If he was the only one focused on shipping, while you others loved to get lost in useless architectural debates, he was the best candidate to team leader.
But the functionalities don't work and generate customer support load…
I should perhaps mention the time he compiled a binary on his machine, committed it on github and went on vacation. And then we couldn't fix the bug that needed urgent fixing.
> Corollary 1: clean, maintainable code is only important when you have customers expecting maintenance.
We do have customers yes.
> Corollary 2: in the Real World (tm), the alternative to technical debt is getting out of business.
You're defending this guy so much… why so defensive? Do you reject the notion that incompetents exist?
> You're defending this guy so much… why so defensive? Do you reject the notion that incompetents exist?
I'm not defending him. I'm just refuting that a developer's competency can be judged without taking into consideration, first and foremost, the benefits he produced for the users of his software.
Not testing your code though. Places that value that shit speed at any cost eventually go bust, it is not smart and indicates a dumb culture which probably carries over to strategy and financials. That has been my experience. There is a basic level of standards. No need for architectural astronauts or monad fanatics but some sanity!
I agree with you, and it's very simple to define such a level: use as much discipline as you need to ensure shipping features at an acceptable rate in the long term.
Too much polishing lowers your release rate. Too little discipline will hurt the "in the long term" part.
Thats a good way to put it. Shipping value rather than features though. Which is represented as long term shareholder value, but within some kind of ethics (don’t fuck the customer type stuff).
Thinking in terms of value could mean you sometimes suggest weird things like removing features, cancelling WIP (sunk costs) etc. when appropriate. Or spending way more time polishing than seems necessary or conversely getting something out that looks way too quick and dirty. There are cases where no tests are OK despite what I said but usually MVP stage stuff where no market fit exists yet.
Have you experienced just speed. Or speed at any cost? I.e. releasing really buggy features that customers complain about and churn on? Obviously with enough VC and marketing dollars anything could be possible.
If everyone else is spending all their time cleaning up the broken shit he built but won't fix, and he continues to produce more broken shit faster than everyone else can keep up with fixing it, he is a 10X programmer. Not because he's actually 10X better, mind you - he just makes everyone else 10X slower.
Shipping broken, especially code that looks ok but it secretly broken - is far worse than having no code at all. Once it's in place, it gets dug in like a tick, and if it's a pile of poor assumptions and wrong logic, you're in a much worse spot than you were with a clean slate.
4.1.00175-update3: Never buy version x.1 from a company that never ships version x.0 of anything.
This kind of company is often run by people who think "People don't buy x.0 because they're afraid of bugs, so always ship x.1 as though we fixed the bugs." while failing to actually do the QA to earn that version bump.
Which predictably results in customers refusing the company's x.1 because, in their own words, "I'm not going to pay to be their beta tester.".
> The only skill you need to get promoted is to laugh at the jokes of your boss and schedule meetings to demo your n-th rewrite of the same thing.
You can't choose your colleagues, but you can choose your company. Some of them have fair evaluation processes and try hard to avoid biases. Same thing for meetings, not all companies/teams have long meetings.
I'm only learning to play correctly in mid-career. No amount of being good at technical stuff will get you promoted in most orgs—maybe to mid-tier dev levels, but not much higher. Being hyper-social, will. Not the normal amount of social you need to be to do a good job as a developer, but spreading out your "footprint" on purpose so you're known by and often interacting with a lot more people, even if those interactions are actually a drag on overall productivity. I've learned from observing others who are good at doing a lot of talking in meetings, and who eagerly start adding shit to people's calendars and stuff their first week. It fucking works. Reliably. Be bold, and be noisy. Get promoted.
I disagree with this statement in general. Institutions/nature (the game) cannot be held accountable. Persons can be. If we want to change the world, it starts with changing the behaviour of individuals, slowly changing the institution.
The person who needs to change their behavior is the hiring decision person. The player is just making the best of his situation. The fact that the game is running means the most likeable person will be promoted, even if they aren't liked much.
> How long does it take you to go to the store? Yes you might die in the process and take ∞ time, but one normally considers common inconveniences in this. A senior who can't estimate isn't a senior.
A senior who can't navigate the politics around estimating is missing key skills. But they still can't estimate. To estimate something you have to know what you are building and the steps to take to build it in advance. Senior engineers usually don't have enough political weight to stop that changing half way through a project and therefore cannot provide estimates. They can estimate hypothetical scenarios that are unlikely to happen.
There's a three-pronged approach when dealing with it:
- Pad.
- Communicate risks.
- Communicate assumptions.
Then when assumptions are wrong, immediately communicate that this will change the estimate. When risks hit, communicate that a risk hit, and whether or not you can absorb the impact in the planning. If not, communicate the expected delay. Pad that too.
Communicate, communicate, pad, and communicate.
(Padding, BTW, may feel dishonest, but it isn't. It is making the assumption that a certain share of you risks will strike and making allowances for that.)
If you still get in trouble for missing estimates, pad more and communicate in writing. Then when people start blaming, you can point to the emails sent. To their/your boss if necessary.
> (Padding, BTW, may feel dishonest, but it isn't. It is making the assumption that a certain share of you risks will strike and making allowances for that.)
This. It helps to realize that when someone asks "how long will X take". What they are actually asking is "When can I rely on X being done by?". If you say 2 days and it takes one, no problem. But if you say one and it takes 2, they've already told the client it'll be done tomorrow, arranged for the machinery to be in place, and now everything is jammed up based on your delay.
Estimating is as much art as science and requires understanding the context around the estimate and how it will be used.
also offer alternatives, preferably at the same time you communicate the risk. When the risk hits you can then start making recommendations about the workarounds you've already communicated.
This stuff is fluid but too many technical people feel as if it's not.
I dont know if you are joking but when managing i do exactly that and that work (with a factor of 3 to be precise, with most people, some aldready take that into account). Works also with myself, i askmyself 'how much i think it will take, i double it and i assume half the day i will be bothered by other unplanned things'. It work remarkably well especially for longer projects.
> I've overheard a team lead claiming they are completely impossible.
How big was the team? What were their responsibilities?
I have worked places where, because of bad management, we dropped everything to shift to other tasks so often that it was nearly impossible to estimate anything.
I told a guy I mentor this once. You can make a career out of only knowing the right people and you can make a career out of only knowing the right things. The situation you want to be in though is knowing the right people AND knowing the right things. That’s where the real money is.
Eventually my team lead asked me what was going on (he probably had gotten complaints about me breaking the tests).
I told him what I had done (which is easy to show in a git show commit_id) and I guess he responded to them saying that we would not revert the change.
In general I prefer to not have in person discussions for conflicts, so that there is a trail left behind, and I can take hours to respond, so I don't get heated up.
> After writing countless emails to convince him to fix his code, and wondering why they wouldn't just fire him and save everyone else some time, the CTO announced that the guy was now promoted to team lead. :)
It is. commonly known that some good developers make poor leads. Could some poor developers make decent leads?
After all, most serion management has never seen an if-clause, are they any better than this guy?
Maybe. But if the accounting is accurate, this person refused valid, and urgent criticism. They refused all input, and eefused to care that there was an issue.
This would make a very poor team lead. Imagine this person taking the wrong path, then refusing to acknowledge so. Imagine them upset that "their" path was being constructively criticized.
This is how companies go bankrupt, how months or years of work result in garbage.
He gets promoted = double click cv.doc and get updating for me. Team leading is about people but fuck you need some level of competence. Infact I say you need more technical skill in some ways to be across everything. How will this TL have
high standards if he short circuits his unit tests and then fiercely argues for it?
With Haskell, if it compiles then it works. But not for the reason people think. If you spent the time learning Haskell, you probably are smart, conscientious and thought quite hard about your program.
That said type obsessed people invent things like property based tests (basically fuzzers for math people). They test the shit out of their code!
I would almost add another point to the list of 10 points: Your worse software engineering colleagues will often get promoted to do something else. Expect them to become your team lead.
>And he could find the same amount of deficiencies in your own code.
I'm amazed how many people in this thread seem to believe that it's literally impossible for one dev to be less competent than another, let alone by a significant margin. John Carmack is objectively a better developer than me, and by a huge amount, but I don't feel ashamed or like a lesser person because of it.
Thing is, I don't search at all. I just find them because they stand in the way of me doing whatever it is that I'm supposed to be doing instead of debugging his code.
Also, when people find a bug in my code (which does happen, naturally) I don't spend weeks trying to gaslight them into thinking there really is no bug. I just fix it :)
Is there something wrong with archive.ph lately? I only get infinite captchas. Yesterday same thing on another article. It was a great service when it worked.
> Because if you promise to deliver it by Tuesday and you run into some problems, you won't be able to fulfill the promise. Instead, if you accept Friday as a deadline, and you finish it by Wednesday, you can deliver it 2 days earlier.
Or you can deliver it on Friday.
I once had a boss that taught me an important lesson. Some other party (business unit or company, I can't remember) asked for some work to be done. He said for me to not work on it right away. I said I could get it done in a couple hours, so why not do it right away? He said it was to manage expectations and not give the other party everything they want right away or they'll come to expect it.
Edit: I also wasn't to start it right away because the work may not get done at all. Some of it was to delay to determine whether the work was even necessary. And some of it was to push back to ensure that we're not ALWAYS giving in to every demand.
Yeah, that's... awful. The real problem isn't that you do this, per se, but that you're not incentivized to improve the business. You should want to hop on this and deliver it in a couple of hours; it's up to the business to make that something you directly benefit from.
> The real problem isn't that you do this, per se, but that you're not incentivized to improve the business
But I'm not. It's not my business.
I have almost never worked at a place where there were incentives to go above and beyond; few places reward that behavior with anything except more work and a cost of living raise.
Having said that, I've definitely been incentivized by the relationships I've built with people: I've jumped in to fix a problem for another team because we're friendly with each other, and I've prioritized fixing some bugs because they were impacting users (and given my employer, I like our users as a class of people and want to do right by them).
But I've never once thought to myself, "This nameless group of people working seven states away that I've never met or spoken to asks something of us, I should definitely prioritize it!"
A company is nothing more than the people that compose it. If the people in the company who want you to do work don't build a relationship with you, they have failed to run the company successfully.
Agreed, but as someone doing software work for a non-tech company with tech-illiterate leadership, it doesn't happen. Which forces you to play this game, or you'll find yourself drowning in impossible demands because the business side doesn't understand why things they want to do are so often pivoting around their technical staff.
If you're reading this, this is what not to do. Plan your work, expectations of delivery should be on those milestones of sprint releases or whatever yard-stick you are using for planning. Simply doing work as fast as it comes in is a sign that you have no planning. No road map. No future outlook of feature sets. You are flying by the seat of your pants.
This isn't a lesson to learn, it's an anti-lesson. Yes, don't work on things right away and deliver right away as your "customers" will expect it, but why is that a bad thing? Why can't you easily deliver features when they are ready? Why is this boss giving you such bad advice?
I may have oversimplified it. There were certainly other factors at play in the boss's mind.
The other part of it was to not do extra work for the third-party when that work wasn't specified in the contract. If you do extra work every time you're asked then it'll quickly be abused. You don't want to seem like a contract stickler, but you also don't want to bend over backwards either. It's something to keep in mind.
That's a maladaptive approach to the problem, is the point. You should have the communication skills to do additional work when you can and firmly say no when you can't. That's how an adult handles that situation rather than through deception and avoidance.
Of course, there are external reasons that may make this more difficult, but IMO 2/3rds of the reasons people cite for doing things like this are solvable with proper communication. 1/3rd isn't, though.
I understand their position, I recently had a chat with a guy in DevOps, I'd made a request I knew would take at most, 5 minutes. He said he'd try to get to it by the end of the week. That would potentially have caused my story to carry over to the next week.
I opened a Teams chat and asked about it. He said his manager told them to manage expectations. He said he'd cut me a break since I was technical and would understand and got it done in 2 minutes.
A classic book called The Phoenix Project talks about ways to manage this. If I recall correctly, teams can fall into a vicious cycle where they only respond to immediate problems and, therefore, cannot schedule and prioritize their work. By maintaining a work backlog that gets prioritized and saying no to everything else, the team can ensure their work capacity gets respected and not get flooded with more than they can handle.
So, in this way, your DevOps coworker is right. However, I don't think it's true when a team isn't at capacity, which is the scenario I envisioned when I replied. In the case where it costs little to nothing to quickly meet another team's request, the mature thing, IMO, would be to either a) do that thing or at least b) engage in good faith to put the task into your work backlog and prioritize it based on the larger impact of the overall project to the company as a whole. When a team isn't at capacity, the work would be done immediately while simultaneously reinforcing the value of the process to protect your work capacity and prioritization ability. Everybody wins.
I suppose this is what I mean by "maturity"; teams have established processes to protect the team, but if the process allows for additional work, it's maladaptive to gum up the works just to keep expectations low.
...but that response is the "full PM" treatment; that's what I'd tell my boss or answer in an interview. In reality, I think of process as a "backstop" of sorts. You invoke process only when you're reaching some kind of capacity or limitation. If it's no sweat, just do it.
This is the way. If you aren’t at capacity then the manager can step in and say “yeah, we can do that, let me get a ticket/issue/record of it so we can track it” and then proceed to work on it. This works in Kanban really well. If you are at capacity or have planned a sprint already and are midway through the run, it’s ok to say no and get it prioritized in the backlog. If you’re DevOps and the Ops part of the role requires you to respond to tickets in a timely manner then this breaks down.
What we are saying though is that having a plan is a good thing. Protecting the plan is a good thing. Adopting work and helping others is a good thing. The work being adopted needs to be planned and prioritized though. If it’s a small task (like the OP said, it was a 5 minute thing) than opening a chat with them about it after creating the necessary record is fine. The fact they agreed (regardless of classification that they were technical so they would understand) shows there’s hope in your org for empathy.
What you shouldn’t do is say no to adopting the work while you sit back and play wordle until you feel the person has waited the necessary amount of time. Also, don’t write systems that require 14 approvals and a shaman and waiting 48 hours for a status change before you can begin work.
Not necessarily; only in the worst cases would a coworker actively harm you for not helping them once you've established that you can. I've worked with fairly immature people who can still be guided by my maturity.
Of course, you're ultimately right. Some people just can't operate professionally, but I find those people to be rarer than they may initially appear. It's far more common to write someone off too early.
Not sure I agree with not starting work on it right away so you don’t finish early but, I’ve learned that constantly delivering earlier than you say can make people not believe your estimates - ditto for always being late
It is extremely easy to disconnect from work. Turn off your laptop and live your life.
I find that those who are chronic workers have very little going for them in their personal lives.
I challenge everyone who feels overworked to work 1 hour less this week, then an extra 1 hour next week. See how far you can go before anyone even notices or cares. It’s farther than you think.
I often find myself at totally random moments thinking about problems related to work. It is often at times that I have been away from the laptop, that solutions pop-up in my mind, for a nasty problem. Often it is form of attacking a problem from a different direction.
For me turning of my work laptop is not enough to disconnect from work. Most of the thinks that I worry about while being at home are not about technical aspects but about non-technical aspects of the job: dealing with managers, colleagues, and project organisation.
> I often find myself at totally random moments thinking about problems related to work. It is often at times that I have been away from the laptop, that solutions pop-up in my mind, for a nasty problem. Often it is form of attacking a problem from a different direction.
I get this too, all the time, but I don’t see it as a problem. This is what the mind likes to do: chew on problems. It’s not realistic be expect to be able to prevent your mind from trying to solve problems. All you can really do is to not pay it too much attention and it eventually dies out.
If a solution to a work problem pops into my mind, I just write down a few key words on my phone and continue with my day. Then I revisit the notes on my next work day.
Same here. I have no trouble "closing the laptop", but I can't stop my mind from problem solving. Fortunately for me I don't have any of the "soft" concerns you mention.
The practical side is clear: close the laptop. But on the mental side I do wonder where the right balance is. I've recently started to forget about work at the weekends to the extent that - usually late on a Sunday - I suddenly remember I have to be at work the next day, which is an odd sensation. Probably just getting old(er).
Looks like you just had busy and nice weekends then. I get the same deep reset weekends sometimes, especially when I also take Friday off. Then the next Monday morning I barely remember what to say at the daily stand-up confessional.
That sounds like anxiety. Nothing is so important that it can’t wait for business hours.
And if the company will fail or you would be negatively judged for only working on business hours, there are always other jobs.
Writing down a shower thought that hits you out of your subconscious is one thing, but actively considering work topics off work time is working more for the same pay.
My interactions with colleagues are pleasant enough that I don’t need to worry about them at home. And things like “resource allocation” happens on work time
If you are getting paid as an engineer, let that happen. Don't ignore ideas just because it's off hours. You don't have to let that thinking take over your life: make a note of the new idea and get to it monday if you want. But these solutions are precious. When they happen, they happen.
That section of the article unfortunately conflates two types of not switching off.
* Late at night, quick check of my email or Slack and maybe even reply (either to get it out of the way or to show off how hard I'm working).
* While I'm in the shower, thinking about some interesting logical problem (can be something mundane like how to clearly express something in a report).
What is healthy and what isn't is subjective. But most would agree the first is not healthy, while some would say that the second is OK. Personally, I think it's fine (nice even) and certainly doesn't interfer with social or family life.
You (comment I'm replying to) have added a third which is quite different: "chronic workers" are those that are flat out working for extended hours. That's not really the same as not being able to switch off.
Considering that the author of TFA assumed (wrongly) that his inability to disconnect from work is a universal problem, I don't think it's fair to criticize the comments here for just following his example.
Couldn't agree more. Worked with a guy and he would respond on slack almost immediately-he was addicted to work and having the app on his personal phone. he had nothing else going on in his life.
Personally, if I shut my laptop there is no way to contact me for work related issues nor should there be.
That’s hideous. If you are going to carry it around everywhere anyway at least use your work phone for everything. That way you get at least some of the upside (work pays for it).
> It is extremely easy to disconnect from work. Turn off your laptop and live your life.
The problem is not that I can’t stop work. I can sit around for a week and nobody would notice. It happens.
But when I do work, I care. I want it to be nice, beautiful and make everyone’s lives easier. And I want that now. I cannot just flip those switches off when I go home (or am home, when doing wfh). It would probably be objectively better if I rested my mind a bit, but my work happens in big bursts.
It is, and yet I suspect many chronic workers can’t recognize it as one.
It is obvious from a Birds Eye view, but those stuck in the toil rarely understand that they are losing their chance to build a meaningful life apart from work.
I don’t take any job where I would have to wake up from sleep to handle something. Some jobs have stated on-call, but the consequence of not handling a 3am call is nothing. In which case you make more money/hour by not responding to night requests.
The products I’ve worked on in my career largely operate on US business hours, so this has never been a real issue for me.
If I were receiving calls about work more than once a year, I’d quit.
lucky you. SWE job elsewhere in the world (or maybe if you are on H1B in USA) implies 24/7 oncall duties. or you and your family get deported where you come from.
and you can't just quit. you quit, your visa immediately reworked, as tied to your employer. and again. deportation.
Do other careers have such a vast gap between the platonic ideal and the actual lived experience? The way most people talk about software engineering, you'd think they were some kind of open-source warrior building entire applications from scratch when really they're on the Cancel Prime Membership Button Obfuscation Enablement team at Amazon.
I think people like to role-play doing the job before it was professionalized because then it sounds less like you're a cog in a machine.
> Do other careers have such a vast gap between the platonic ideal and the actual lived experience?
In the past few years I've got the impression that when I go to a doctor with a slightly unusual symptom, they are very much lost. It seems the average GP learned a whole lot at University, and 20 years later treats the same 50 common things (colds, cuts, high blood pressure, you name it) and doesn't really remember all the quirky and exciting stuff from uni.
I'd guess that the more academic the education is, the more likely you fall into that pattern.
It's not really for laypeople, so you can't poke around in there (check your alumni benefits though, many associations have subscriptions). But, to give you an idea, the site is pretty much a diagnostician. You can just plug in symptoms, patient history and demographics, and it'll give you nearly everything that you need to know. Lots of best practices, research papers, summary papers, testimonials, etc. It's effectively an AI for MDs, and it's good.
What I'm trying to say is that your first instinct is correct: The MDs that you're going to really are in fact idiots that can't even be arsed to use a web form.
Not sure why people are downvoting this - my partner is an MD and uses uptodate literally every few hours, when she's at home - I'm sure it's higher at the hospital/clinic.
Some Doctors are checked out/lazy/make assumptions, just like everyone else.
Definitely. Resources like UpToDate are invaluable. Patient safety research proves it. Just double checking something to make sure reduces errors.
Better not to do it in front of patients though. Many will assume you're incompetent if they see you doing it. Few will understand that you are a fallible human being who's using every possible resource to make up for it.
unfortunately, many (most?) doctors have simply become prescription writing machines - "got a problem? there is a pill for that", and if that pill doesn't work, we will try something else.
Good luck finding a MD that actually wants you to be healthy and drug free - the system is setup to give you a prescription and hope that it works; doctors around me won't even broach the subject of suggesting you lose some weight or get more exercise or even just eat more healthy food - they just write a prescription to deal with the adverse affects of your poor lifestyle.
In my experience, it's the opposite. Day in day out I tell patients to exercise and eat better. Some people manage to change their lifestyle, get better and even get off medications such as statins. Many don't and medication ends up being the only thing keeping things under control.
Then there are the patients who will destroy you on social media when you tell them to take some responsibility because that's "intolerance" of their morbid obesity. Plenty of people out there looking for easy pill solutions to everything.
Yep - I have several family members that work in primary care - many patients have filed formal complaints with the practice if the provider calls attention to the fact that someone is obese or is making unhealthy lifestyle choices and should make changes if they want to be healthier - one even threatening to sue if the office didn't take references to her chart that said she was clinically obese - so more and more providers are simply not broaching the subject and instead writing the prescription for whatever the pill-de-jour is.
I can't remember how long ago, but I read or heard about a few studies that show you're better off going to a freshly minted doctor, at least in the US. They'll not have had the time to build a cynicism around "what they learned is all they need to know".
I know Dr's learn a lot throughout their career, but after they get into a practice they just don't have the time they did in medical school (or won't spend the time), and the trajectory flattens.
It's the same in software and likely every industry. Yeah, you still have plenty of very senior folks who have adopted the cloud and are building things in modern ways and on the bleeding edge of things. Then you've got the crusty HN types who think a Hetzner VM and Postgres is the best way to solve all the problems in the world and javascript is the bane of all existence. I've met the 50 year old developer who has written nothing but Java enterprise apps for the last 20 years who are all but useless outside of their niche, and a 60 year old developer who is still as giddy as a child while he's playing with code generation models. If technology is your passion, it's far easier to stay up to date and stay relevant. If technology is just your chosen career, you've got to intentionally put in the effort to stay up to date or risk becoming out of touch with the industry. There are passionate doctors and career doctors. Passionate home builders and career home builders. Etc. Etc.
A research oriented doctor is going to have very little interest in anything but their research. So if you know you have a rare disease, sure. But most people do not.
I used Northwestern for years and my internal medicine doctor always seemed more up to date. The specialists he referred me to were often involved with the university in some capacity and seemed to be aware of very up to date info in their fields.
General practice and primary care are all about what's common. It's designed to soak up all the easy stuff that makes up 80% of the cases so that the specialists can deal with the hard complicated 20% stuff. If a doctor can't help you, they should still know who to refer you to.
Can you give an example of a slightly unusual symptom that stumps doctors?
Yes- I've had the same experience... the same "Huh, that's weird" kind of unknowing response that I give my parents when their printer isn't working again
Both of those experiences exist, though - if you want to build applications from scratch, go join a really early stage startup. It's strange to me that people are surprised that when you're one of hundreds or thousands of software developers in an organization that you don't get to work on freewheeling projects based on what you want to do.
Also, I don't think there's a platonic ideal of a software developer - there's a lot of mid-40s devs who have children and whose platonic ideal is a well-paying job with good work-life balance.
>Do other careers have such a vast gap between the platonic ideal and the actual lived experience?
I'm not paid boatloads of money for 99% of my work, i'm paid boatloads of money for the 1% of the time I have to do something very impactful. If using the right data structure for your 'cancel prime membership button' means a .1% server load reduction and 1% higher reliability, it's worth paying Joe Blow Amazon SDE 300k a year.
It's the same with Doctors. Most of the time they say "take two Tylenol and call me in the morning". Or maybe they're stitching someone up in the ER and they're doing just as good of a job as a nurse. But once and a while they save lives with their decision making.
Yes. Pretty much all of them. Most jobs are more about the realistic situation on the ground. Very little of which is "platonic ideal"? Even if or when you get to have a whole team of assistants to do the menial stuff you don't consider part of your "platonic ideal", you'll find yourself in the management and coordination business. A good manager will shield you from some of this but most of the job IS this. People tend to talk about the fun stuff but the good news is, you are reading HN so you also hear plenty about the not fun stuff.
> Do other careers have such a vast gap between the platonic ideal and the actual lived experience?
I used to really enjoy this blog from this american medical student. This guy seriously hated medical school and the worst part is I don't even blame him.
> The way most people talk about software engineering, you'd think they were some kind of open-source warrior building entire applications from scratch when really they're on the Cancel Prime Membership Button Obfuscation Enablement team at Amazon.
True, if one apply most of the lessons in the article (e.g. "Nobody gives a f** about your clean code") to a well-established open source project, the maintainers will grind you to death.
+ Compensation is insane. I don't think there is anything else in the world I am qualified to do that would pay me nearly as much.
- Deceptively long hours
- Constant deadlines that are often solely dependent on you. If you are at the senior level or higher, there are often features that depend only on you. If you miss a deadline, several people up the chain will most likely know about it. There is no one to share the "shame" with. It's all on you.
+ Flexible schedule. Every place I've worked has been very accommodating (usually to the point of not caring at all) of family obligations, doc appointments, start time, etc.
- Constant objective changes. Speaking from FAANG, things are constantly changing. You could be months into a feature, priorities shift, and they shelf the whole thing. Not to mention the re-orgs.
Overall, I feel very fortunate to have this career. I often see folks my age grinding away at some soul sucking job and my gratitude intensifies. However, it's not all sunshine and rainbows. The nap pods and ping pong tables are just a recruiting tool, not part of day to day life.
I'm just saying, compare what you're making to the average person your age. Take into account the amount of debt that comes along with some of the professions requiring extensive schooling. Also consider the conditions and work life balance (ex: welders can make a great deal of money however they are often away from home for months and work 6-7 days a week in rough conditions).
Even if you're not at FAANG, overall, we're making a lot of money working from a comfy chair with little to no required debt.
Have you worked with people at the same professional level outside of FAANG? There are a lot of companies outside of those BigCo tech companies that pay well without the stressors that you mention.
Comp's not insane in the rest of the industry, but is just about the only non-management route to the 1960s-1990s style middle class that remains. It's a lot of money compared to median income.
Even outside of FAANG the pay is still quite generous, at least from my experience in.... US/AU/UK/etc
You get paid so much for relatively so little. Housemate was a chef who's work was so much more demanding physically and worked stupid hours, and was paid a fraction compared to developers.
This is the rub right here. Huge mental overhead that is often not mentioned.
Not only the potential for great consequence (think errant deployment in AWS S3 that takes out an entire region and costs the company millions), but the requirement to constantly be evolving and learning new things. Not only learning but being proficient at them. All while not forgetting the original stuff you knew.
> the requirement to constantly be evolving and learning new things.
when is this not the case?
there are no fields that pay well where stagnation is acceptable. not in (real) engineering, not in the sciences, not in legal, business, marketing, etc.
I have never encountered a profession that complains as much about their job as Software Engineers. I've worked many jobs in my life: restaurants, construction, teaching, IT Support and so far the best one has been software development. Every job has its annoying BS. I get it's not for everybody, but at least I get to solve puzzles all day instead of digging post holes or dealing with shitty customers.
I wonder where you live for that to be true, in my experience everyone just complains all the time about the previous guys' craftsmanship and that's especially true in trade and engineering.
> restaurants
KitchenConfidential is a subreddit dedicated to complaining about shitty customers.
> construction
If you don't hang out with construction worker, you can find almost any YouTube video that goes over some aspect of homebuilding, scroll down and see comments with "As a carpenter of 15 years that guy is a moron for X and Y".
> teaching
I don't have public examples of that one but a lot of my friends are teacher and they are an absolute blast to be around because they keep complaining about stupid helicopter parents, overbearing principals and other bad encounters. No idea what kind of teacher you hang out with. Same goes for doctor and nurses btw, put two of them together in a room and they will start complaining about patient X and Y.
> IT Support
There are 4-5 subreddits like TalesFromTechSupport that are literally only stories from IT technicians.
All of the above to say, really happy for you if Software Engineers are the ones that complain the most.
I don't think it's that unique, it's just that creating your own website (even if it's a hosted blog of medium or whatever) is not really something most people do.
Plenty of people complain about their job on reddit or twitter or tiktok or whatever. Internet is full of it.
Outside of SEO, marketing, and other sales-adjacent purposes, software developers are some of the only people with indie blogs anymore, which I think explains this. The practical difference between posting on my blog about ugly code and posting on a subreddit/forum about ugly code is primarily who owns the data and where it is stored. The restaurant workers are still doing a similar type of venting.
One unique aspect of software engineering is that it is still growing exponentially, doubling approximately every five years.
As a direct consequence of the mathematics of exponential growth, this means that:
HALF of all software developers have LESS THAN 5 YEARS of experience!
This results in experienced devs being simply outnumbered by newcomers and having to perpetually fight against the rising tide of beginner errors.
As someone with nearly four decades of experience, I'm facing six such doublings (plus retirees subtracting from the experienced pool!), meaning that I'm outnumbered by people will less experience 64-to-1.
In my time I've seen every wheel reinvented -- badly -- at least three or four times over. I've seen the same huge, glaring mistakes made over and over by new people. It's literally impossible to convince them of their mistakes because it's one voice against dozens.
Few if any other industries are like this because they don't have the same insane growth curve. Surgeons with less than 5 years of experience are hugely outnumbered by surgeons with 10, 15, 20, etc... years of experience all the way up to 50+. They don't get to overrule the Chief of Surgery. They're told to shut up and learn how to do things properly by people who made mistakes and learned from the consequences.
As a random example of this effect, the entire industry is learning for like the third or fourth time that text-based formats are not better, and their "ease of use" is a deceptive trap.
JSON is just text, and is "so easy" -> gRPC, a binary wire format.
HTTP is just text, and is "so easy" -> HTTP/3, a binary protocol.
This kind of thing will keep happening until the exponential growth transitions into the flat bit of the S curve, and the average experience level starts climbing towards two decades.
Pete Davidson joked that depression is a rich person's condition because it implies you have a life you shouldn't be depressed about. Same with software engineers?
I know mental health issues and suicide attempts correlate much more strongly with folks lower on the socioeconomic ladder, but when I was poor I was too busy to be depressed in the same way I am today. Now my life is far easier, yet also somehow much more depressing.
having grown up extremely poor, I agree with this sentiment.
But it's also more than that. I hate using this word but I think it applies here.
Poor people don't have to the privilege to stop and whine.
- When I was a teenager I had a flat tire and the spare was flat. I knew of a tire shop a few miles down the road so I pulled the tire off my vehicle and walked it the several miles to the shop. The shop was closed because the guy had called in sick. It was another 15 miles to town, so I started the walk. Thankfully someone took pity on me and picked me up after a couple of miles.
- When I first graduated college I didn't have a working vehicle but got a job miles from the house. I would leave around 3am and walk for 5 hours to be there at 8am, then hitch a ride home. I did this until I could afford a bicycle, which I had for about a month before someone stole and I was back to walking.
- I know a woman who recently (w/i the last 2-3 years) was talking about how when her vehicle broke down one night she ended up having to walk 12 miles back into town.
For poor people there's this hard wall where if you stop it's akin to laying down and dying, the results are catastrophic. So you do what you must. People who are not poor often don't understand how it is that someone can't or won't take the time to talk to a therapist about trauma. They can't afford it either in time or money.
Almost every teacher I've known has complained a lot more than most of the S/W engineer folks I know. I do complain a bit myself though, but I think that's a reflection of having high standards and an eagerness to improve things (to put a positive spin on it).
You do make a good point though - we don't have to work in the sleet, or in human filth in a 2 foot crawlspace filled with spiders. It could be a lot worse!
I complain because the impact I can have on people's lives now is far greater than when I was working fast food or picking orders in a warehouse, but the people I work with either don't give a shit or are incompetent. Then we wonder why dealing with various companies is so irritating and they create so many problems in our lives.
The point about "incompetent people" is a bit harsh. "Competence" is rarely boolean - some people are smarter, some are less smart, but may have other qualities (e.g. being more thorough), some may not be that familiar with a certain technology etc.; that code you have to work on may look the way it looks because it had to be adapted several times to changing requirements without enough time to refactor it properly, not because the person who wrote it was incompetent. There are already enough young developers leaving university full of self-confidence thinking they are God's gift to the job market, so maybe a word or two about giving people the benefit of doubt before classifying them as incompetent is in order. That's not to say there aren't really incompetent people, but you should avoid jumping to conclusions too early...
Maybe, but the people I have worked with have been pretty heavily bimodal, especially by the senior level - many people in the "competent" bucket varied a bit but generally produced workable code (maintainable as well as works now). But there is a distinct class of senior engineer that produces awful code that is hopeless to work with later. Most frustratingly, it does actually work for the current task so those outside the system will only see problems with the later devs to work on it.
If I say something like "I've got my sales history in a database and need to graph how many widgets I've sold over time", do you start thinking about concepts and code, or do you start drooling and typing "npm database npm graph npm widget..."?
Seasoned pro-tier for that specific sort of problem is just batch-exporting to excel and letting it do the graphing, or hacking something up in Power BI or whatever.
One point to make about thrown together solutions, in the following video: https://www.youtube.com/watch?v=TmhQCQr_DCA at time 8:32 he changes Units Sold column from Decimal to Whole Number. For the trivial example, it would probably be fine but it could also be a costly mistake in other scenarios.
We all start from somewhere and nobody was born starting from perfect.
First label your fundamental concerns. You cannot improve what you don't measure.
Error-prone code? First number the errors then classify the errors. Are your errors related to typos or do they come from not handling variable input gracefully? Now reduce your numbers by consciously finding typos, or by consciously mapping out just what inputs could possibly come in. Miss one? Write it down and never miss it again.
Meetings? How many times do you get "well actually'd"? What specific areas do you get asked questions about?
Coworkers? How many times do you get asked for help? How many times do you ask the same question -with or w/o a subtle variation- more than once? How often do you reach out to just shoot the shit? How often does someone approach you for water cooler talk?
Or (more likely) you just _feel like you aren't competent. Having hard numbers will go very far in getting a more objective viewpoint there.
Being wrong occasionally is human. It is not the same as being incompetent. There truly are numerous people in software engineering who don't know what they are doing at all.
Nope. There are extremely incompetent software developers out there. People who are so incompetent that removing them from the team increase the productivity of the team. After 30 years of working on software teams around the world my conclusion is that 1 in 10 developers are really good and worth working with. 8 in 10 are OK for routine work but don’t let them make any high level architectural decisions. And 1 in 10 are so incompetent that they should be removed from the team.
On my current job, one guy took over a month to "write more tests for service X". He was finally fired (took over a year despite being clearly incompetent, and they had multiple opportunities to not renew his contract). After that, I saw that he had only written 6 tests, which were quick copy-pastes, and largely useless. Maybe this guy had some positive qualities, but writing code was not one of them.
Another guy on this small team writes garbage code. Like "if (condition) true else false". He does have some redeeming qualities, but has caused huge amounts of bugs and tech debt despite being one of the most senior devs on the team.
My code is not perfect, I've done the occasional bonehead maneuver and had dunning-kruger when I was young, but there is just no comparison. The majority of devs on this team are not shit; we know who the shitty ones are.
I'm on the fence. Not initially, sure. But there are embedded lessons that click later.
I was ten years into my career before I needed to write a b-tree or a double ended linked list, but when the need arose I was very grateful for having the ability to recognize it, and the familiarity to act on it.
Some things I learned such as the wonderful value of pure functions just didn't click for about as long. I'd done a ton of Scheme in College and at the time it was nothing but a frustration "Just let me mutate state, this is dumb" it wasn't until I had years of tracking down what the heck was mutating state in a giant old code base that I learned to appreciate functional programming.
Do you need college for that, though? I don't have one and still know how to implement a double-linked list, trees, tries, hash maps and what to test for when implementing binary search[^1]. Just keep your eyes open.
I was a self taught programmer for close to a decade before going back for a degree and I’ve been working for almost a decade since finishing.
Unlike self teaching, a degree forces you to learn the boring bits as well as the interesting stuff. When I was self taught, I’d flitter around and pick up fun pieces here and there, but with no real focus.
Some people are disciplined enough to teach themselves the equivalent of a 4 year CS degree. Most are not.
And there are people I’ve worked with, without degrees who are far better programmers than I am. But they still tended to have some gaps. I’m fairly certain they’d be even better with a degree.
It's also very valuable to have a shared frame of reference with colleagues so you can communicate more efficiently. Saying things like "this is like backpressure" instead of having to explain the entire concept is very valuable.
I'm not degreed, been working with and for PhD's, people with and without degrees for 3 decades including several stints at valley startups and never heard anyone use the term backpressure outside of a mechanical engineering context.
The best college courses taught me more than my jobs ever did. Creating my own iPhone app and reimplementing rowhammer stand out. The app I sold and reimplementing rowhammer required me to learn about C, assembly and CPU architecture fast. It gave me a mindset that still serves me. And sometimes it allows me to pentest my employer because I smell a vulnerability.
>I'm on the fence. Not initially, sure. But there are embedded lessons that click later.
College can give you a great baseline to build upon. I can't tell you the number of developers with 10 years experience and a degree that I've interviewed who could't explain what database normalization was.
Having said that, the vast, vast, vast majority of stuff I know I learned "on the streets."
I can't remember what I did in CS in college. College was fun and there was a ton of interesting stuff in general, but that's just 1 or 2 years worth of learning compared to working full time for a decade or more after that.
Even on the purely theoretical side I think I learned BNF or design patterns on the job. Same for algorithms, you'll see a lot more going through react's inner workings than sitting in CS courses.
Alleged Agile purists and Scrum Masters with a MEDIUMTEXT worth of Alliance certifications in their email signature who prattle endlessly about SWAGs, cone of uncertainty, “it’s _just_ an estimation”, tee shirt sizes, etc. will corner you with a demand to give the number of days it will take to do x with no necessary details or requirements, make you play planning poker with some other equally bewildered chump, ignore that and write whatever number they already had in their head into the roadmap which will be several months short of your guestimation, and then chastise you and your team for not delivering what they wanted even sooner than that, and before you’re even done they start “knowledge transfer” and “switching to maintenance mode” so they can whisk you off to another equally fucked project; get ready for it.
It’s one big partially dysfunctional cargo cult where your toughest career problems are less frequently technical but political, interpersonal, and organizational.
MBAs and cert-chasers make the worst managers/scrum masters. Give me a former dev who had to code less because they got carpel tunnel or a hacker with only one book on agile methodology any day.
The bullet points in the article are reasonable enough, but almost every explanation is questionable. I’ll just address one.
Soft skills are indeed very important, and sometimes more so than technical skills. However:
> Technical skills are the ones you can learn easily. With different projects, you can understand a particular programming language. You can learn its syntax, pros and cons. It's just a matter of practice.
Technical skills are not just about programming language syntax. I wonder how long the author’s been in the industry (apparently “a lot of years”) or how narrow his role is, that he’s never had to learn completely new concepts or paradigms.
And even the soft skills section is bizarre. What can I learn about utilizing my soft skills from the author’s list of all the times they thought a colleague was unhelpful or “toxic”?
Indeed, I see a big difference between developers in my team based on their general reasoning and discrete math skills. How capable are they of abstractly interpreting code in their head? Are they used to thinking about how to prove something is correct? Are they used to thinking in terms of graphs? That sort of thing. Those are technical skills that seem pretty difficult to learn.
I’d say OP has 5-7 years. Because if you have both soft and technical skills together you stop writing code after about your first decade and start solving much larger problems.
This is bad advice in many organizations. The best architects I've ever worked with were excellent coders and kept up to date with everything even if only 10% of their role involved writing actual code.
It's very hard to be a technical leader without credibility.
In TFA, author uses a swimming analogy and it's alright but for me I find martial arts is the most relatable analogy and so many of Bruce Lee's thoughts are applicable...
A lot of what you will learn in a degree is like doing your katas. They're fun to learn but many (if any) of the moves are too situational and abstract that you'll rarely get the chance to apply them. And when you do, you may forget about them in the moment under pressure.
But learning those techniques in a safe environment you'll have a chance to develop some finesse and also have good technical foundations. But there's no replacement for actually getting field experience by sparring/fighting.
A seasoned brawler/street fighter will seem uncouth and may have some unorthodox habits but they will be more successful in the day to day than most theoreticians who aren't out there applying what they're learning.
Some Bruce Lee quotes I like wrt software engineering...
Adapt what is useful, reject what is useless, and add what is specifically your own.
If you spend too much time thinking about a thing, you’ll never get it done.
Before I learned the art, a punch was just a punch, and a kick, just a kick. After I learned the art, a punch was no longer a punch, a kick, no longer a kick. Now that I understand the art, a punch is just a punch and a kick is just a kick
> A seasoned brawler/street fighter will seem uncouth and may have some unorthodox habits but they will be more successful in the day to day than most theoreticians who aren't out there applying what they're learning.
That reminds me of my favorite Bing Bang Theory scene, on the way to Comic Con their car breaks down. Leonard asks if anyone knows anything about automobile engines. Everyone (theoretical physicists or astrophysicists) raised their hands enthusiastically. Then Leonard asks, OK, does anyone know how to repair an automobile engine? Everyone lowers their hands.
You will almost certainly experience a layoff in your first few years of post-college work. You may or may not be affected directly by the layoff, but either way your first layoff experience makes an impact on you. You will watch others around you who may have even been great at their jobs lose their jobs for no fault of their own. It sucks.
When a layoff happens to/around you, TALK ABOUT IT WITH YOUR PEERS! Every one of your peers will be having feelings. Engineers are not good at talking about feelings. But OMFG seriously, when that first layoff happens just drop everything you're doing, grab a pile of people you work with and go out for a long lunch right away and then talk about wtf just happened. It makes the situation less bad and will help you get back to being productive much quicker. Your boss won't mind, and if they do, they're a horrible person.
> You will almost certainly experience a layoff in your first few years of post-college work.
Or you'll get hired on the cheap right after the layoff, and everyone left behind will hate your fucking guts for it. Especially when you need their help.
- First job: laid off. Found a new position in 2 weeks.
- Second job: wanted to move, so this doesn't count
- Third job: laid off. But I was already looking for new jobs, it just worked out really well for me
For the ones I got laid off - severance pay is always a nice bonus, particularly if you can get a job prior to it running out. Just remember that when a layoff happens, it's can be more beneficial than a loss (both in monetarily and shaking up things a bit to find new stuff to do.)
Very bad gamble if you need the job and a bunch of people just got laid off. If you can afford to move jobs, you would have done it already after the layoff.
My first internship in college, on my last week, my entire organization got laid off. We all went out to lunch at 9am, none of the engineers went back to the office that day. My first job after college, I was there for 6 years, we had I think, 11 layoffs in organizations I worked in, the first one was less than 6 months after I joined. My 3rd job after college, I was there for 5 years, we had at least 3 different layoffs.
In all cases the managers were completely understanding about the mental impact of the layoffs, both for those directly affected and those who kept their jobs and would need to pick up the work of the departing. Never once did I see a manager expect any work to be done the rest of that day after a layoff was announced.
If you ever work for a manager who isn't compassionate during a layoff, I'm sorry, that sucks.
Well, I liked they used MonkeyUser comics. I feel those guys "get it." Sort of like a more tech-relevant Dilbert (without the racist screeds).
I was a software engineer for a long time, and a "first line" manager, for a long time.
Most of the points are correct, but some did not apply, in my company.
For one thing, I worked for a Japanese corporation, and clean code was a really big deal to them. I had a project canceled, once; partly because the code wasn't up to snuff.
If you work for a Japanese company, get used to meetings. They absolutely love meetings. Especially in-person meetings (rack up those frequent flyer miles!).
That said, I really enjoyed the job. It taught me to write Quality code (which means absolutely nothing, for most tech companies), and they treated me and my team with respect. That's not something that you'll get, in most modern tech companies, and it meant a lot to us all.
It's an artifact of their consensus-based decision-making process (they have lots of process).
Meetings are a crucial part of obtaining and expressing consensus.
It can get pretty crazy, but they get things done.
Whenever we look at the way that another culture does stuff (not just other nations -other companies, as well), we tend to look at it through the lens of "That's not something I could do!". We need to remember that their culture is acclimated to doing things the way they do it; for better or for worse. They actually can have a difficult time, adjusting to the way we do things in the US.
We had a liaison that wanted to help things be more "agile," so our infrastructure/process guy suggested daily morning standups (you know, informal, 15-minute meetings in the morning).
He turned that into once-a-week 1-hour sit-down meetings before lunch on Fridays, with a rigorous format.
Consensus-seeking reduces variance. This is the approach to take when failure is expensive. Blindly applying this approach leads to design by committee and wasted productivity.
I will say that the Quality of the stuff this company made was staggering. Not a huge money-maker, though. Their process had levels of overhead that would have most folks on this site, huddled under their standing desks, whimpering.
I have been doing software professionally for nearly 25 years.
Even if the points the author lays out are very true, don't you ever take them in as being true for you.
One thing I have learned in all these years is that you can rule your own narrative in your job. And when patient, factual and not backing down when demanding answers on 'why', you will find out fast if you are made for being part of an often labour heavy workforce.
Fact is that what the authors lays out, is not at all special to software engineering jobs. All industries are like that. We are not special in any way. And it starts by telling yourself that you are not special, but that you differ yourself by having a qualitative integrity - though that will take many years to get and always be in process.
> Fact is that what the authors lays out, is not at all special to software engineering jobs. All industries are like that. We are not special in any way. And it starts by telling yourself that you are not special, but that you differ yourself by having a qualitative integrity - though that will take many years to get and always be in process.
Aye, a lot of the OP points sound like any white collar job.
I've supported OT roles in Aviation and Railroads, and this sounds more or less like any engineering role I've seen.
It's not a bad job if you have what it takes, but the reason we're paid a lot of money is that many couldn't force themselves to do it even if they wanted to.
There's a lot of responsibility, uncertainty and frustration. Very often we're doing something that no one did exactly the same way before, which means there are no clear answers and no one to delegate responsibility to.
Maybe not so much in a junior position; but the more senior you get, the more of that you'll have to deal with.
I agree about soft skills, learning to communicate well and deal with other people is a big part of it. Half the job is really more about diplomacy than technology.
> It's not a bad job if you have what it takes, but the reason we're paid a lot of money is that many couldn't force themselves to do it even if they wanted to.
You make it sound like we toil away every day, almost as if we were breaking rocks or hammering iron. We don't. We have cushy and sedentary jobs that many could do and even more would die to have. Most LOB software development is not special and not that complicated. We don't create unique works of art in every project we work on, although the occasional piece of code does tickle the brain.
There are many software developers working on much more complex things (compilers, OSs, high-performance computing, firmware, rockets, etc) but those are in the minority. And I firmly believe that anyone with enough training and experience can write OS code, or compiler code, or firmware, etc.
> There's a lot of responsibility, uncertainty and frustration.
I'm not going to say there isn't because there's certainly a lot of that, but it's a small price to pay for how good we have it. We also, as an industry, don't deal with more or less BS than other white-collar, office jobs.
I recently had a conversation with a friend going through her (medical) residence: 12+ hour shifts several days in a row, combining hospital work with lectures. Nurses have it even worse. We (software developers) should be very grateful.
Our jobs might not be physically demanding, but many of us are mentally exhausted every day. I don't work an insane number of hours, but the expectation is always that I'll figure out a way forward with limited information and a team comprised of both competent and incompetent people who mostly want to be told what to do. In the vast majority of software engineering jobs, writing the actual code is trivial.
I think in most organizations/teams, there are a small number of people who are doing most of the thinking, so yes, it is probably the same in all kinds of professions. My objection is mostly to the idea that jobs that aren't physically demanding are all comfy and not exhausting.
I never said they weren’t! My objection is to the idea that, somehow, software development is _more_ demanding or exhausting than other white collar professions.
Having worked various jobs, from general physical labor, to technical but still physically demanding, to office jobs, my software jobs have been by a fairly wide margin the most cushy and well-paid. This isn't to say they are easy or stress-free, but I think the OP is saying it's relative. I'm sure there are plenty of easier jobs, but I don't know that negates the general premise.
> True, it's more mentally demanding than anything else.
This is just not true. Going back to my example, doctors and nurses have more mentally _and_ physically demanding jobs.
> Point still stands though.
It doesn’t. There are harder jobs, both mentally and physically. And most software development is generic and not that complex work that a lot of people could do.
We are only snowflakes in the sense that we think we are special, and that comparatively we have very nice salaries (at least in the US).
That’s a fairly common and wrong misconception of how doctors practice. In reality, there’s a lot of analytical work and “debugging” of symptoms. But even if you were correct, I fail to see how it makes it apples to oranges.
Do you _really_ believe coding up some CRUD SPA web page is the most mentally demanding job in the world?
>but the reason we're paid a lot of money is that many couldn't force themselves to do it even if they wanted to.
By this logic, SWEs working in safety-critical embedded domains would make much more than those working in FAANG. I would argue their job is more complex (they have to know failure modes, not just of software, but of hardware), obviously more critical (failure means people may die), and often more stressful because of those reasons.
Yet they generally get paid much lower salaries than FAANG or basic CRUD app developers. It's not because more people can do what they do; I'd argue there is a much smaller pool to pull from. It's because the FAANG-type companies contribute more to the economy (real or perceived). Even if that's bullocks, that's the main reason behind the high rates of pay. Now, you can extend that same fact to non-SWE jobs and the same pattern holds.
After being a software engineer for over 30 year, I agree with all the points. I have come to the conclusion that being a software engineer is one of the hardest jobs. Also because your often confronted with your weaknesses. But that also gives you room to grow. I also have come to realize that being a software engineer, changes how you view the world, because it forces you to think deeper about problems. The problems behind the problems. In sense that alienates you from all those people who do not have to deal with hard problems, are not used to think deeply about problems. And there are a lot of those kind of people in the world, at least a lot that use their voice.
But in the end, I never regret becoming a software engineer, and I also realized that it has profoundly shaped who I have become.
And then you switch to security from being a developer and the imposter syndrome hits you in the face like a truck and you'll realize how easy it was being a developer.
If only software engineering required or even encouraged thinking, let alone deeply.
Formal systems like computer programming, mathematics or accounting do depend on a certain style of thinking, but I don't think it's especially hard or deep. If something it's shallow and simplistic (which of course has its place).
Why? At least I'm not waiting for mathematicians to e.g. negotiate peace in middle-east, produce a room temperature superconductor or raise a well functioning triplet.
(Obviously me doing those is even more unlikely than me doing P=?NP, but I'm not sure how I'm involved here.)
Don't you see the issue with claiming that "mathematics is shallow and simplistic", but then not being able to follow up on that claim by actually solving one of the most famous open mathematical problems?
If it were shallow and simplistic, any moderately intelligent person would be able to do it - yet decades of world-class mathematicians have failed to produce a proof.
I did not mean shallow and simplistic in a way that any moderately intelligent person would be able to do it. Also all (most) mathematics is not P=?NP level stuff.
Especially being simplistic (unambiguous, mechanistic) is a feature for what mathematics is used for.
All you are saying is that you have been been working on trivial software systems and haven't been exposed to anything particularly large scale or complex so far in your career.
Also you must be confusing basic arithmetic (1+1=2) with mathematics in general.
Go read some papers on deep learning architectures or learn about the Fourier Transform then come back and tell us how shallow and simple it is.
Mathematics requires the most sophisticated and deep thinking that the human species is capable of. Very few humans have the raw intellectual capacity required for being a productive mathematician.
> Also all (most) mathematics is not P=?NP level stuff.
The list of open mathematical problems is as varied as it is vast. But even going beyond that, it's clearly evident (e.g. by considering drop-out rates of technical degrees) that most people seem to be having a really hard time even with comparatively elementary mathematics.
> Especially being simplistic (unambiguous, mechanistic) is a feature for what mathematics is used for.
I'll give you "unambiguous" up to a point (there's still enough debate about which axioms are the "correct" ones, though). But "mechanistic" is plainly wrong. The set of true theorems (e.g. of ZFC) is famously undecidable, so there can be no algorithm that can capture all of mathematics.
If you think it is easy, it is because you have a talent for it and have years of experiance. People who are mental health professionals, teachers, doctors, CEOs, all have what I consider harder jobs, but do you think they would want to switch places and be a software developer 40 hours a week? They would think it is too hard.
Yep, everyone I know who isn't already involved in creating software, including a number of people I know who do jobs that I think of as being actually-hard, thinks it seems really hard and magical. Like, not the job aspect of it that we're mostly discussing here, but the "writing the code that makes computers do all this stuff" part, that probably strikes 95% of the people reading this thread as pretty easy at this point. It's just that it's easy to do things you already know how to do.
There is a medium between "easy" and "hardest job in the world".
People really live in a bubble. Try being a nurse working in cancer kid unit for a few years like my wife. Try being a trucker who sees their kids every other week. Don't you think these people would love seating in their chair from 9 to 5 and make 6 figures?
Maybe I misunderstood what the OP meant by "hardest". I sincerely hope so.
There are just different kinds of "hard". I have lots of nurses in my family who have worked in ERs and ICUs, some of whom nonetheless have told me "I could never do what you do". I think they could! What I do seems way easier to me! But that's not how they see it.
Of course, it is difficult to compare jobs with respect how hard they are. One could easily argue that every job is hard. Jobs can be demanding in various areas, such as: physical, emotional, psychological, mental and intellectual.
Some thins, I think, make software engineering hard, is because it is not very visible from the outside. Another reason is also that it is different from other forms of engineering, where the product of the engineering is outside the engineering and where it is often easy to add a margin. With software, a very small bug can have big consequences.
I also think that software developement is a very creative profession, while often not viewed as such, where you are often judged on the basis of your creative output. In a sense software developers struggle with similar problems as artists, where there is often not an objective good or bad. Discussions about coding styles are frequently found here on Hacker News.
I've always liked working in legacy code bases. It's like doing archeology. Seemingly bad code maybe didn't start out as bad code, but was made bad over time because of historical reasons (last minute product changes, time pressure, local changes without understanding the bigger picture). It can be very rewarding to make sense of it. And it makes you realize that any code you write yourself will be legacy code soon too, and someone else will need to be able to make sense of it again.
The thing about inheriting an older, undocumented codebase is that it often blows up in ways that you least expect; even drawing assumptions about how a function works based on its name can be problematic.
Or when you remove some "unused" code, only to find out that it was somehow used by reflection and your IDE can't even figure that out because the framework you're using was discontinued in 2010. Also of course, there's no test for that.
I've worked on plenty of legacy code over 37 years. It all depends on the management environment and how bad the code is. Sometimes legacy code is like being mired in quicksand.
I've grown to appreciate legacy code more than greenfield. It's real code that makes money (hopefully) and solves problems. Code is bad? Well, it's probably for good reason as real-world problems are messy. Also a lot less analysis by paralysis.
> The user doesn't know how the codebase looks. The user just sees what features that product is offering. So don't get overly attached to your clean and elegant code. Focus on shipping the feature on time and bug-free.
This is a slippery slope. True, the user doesn't see the code. But they do see the feature set (or lack thereof), and the speed at which you're able to update that feature set to suit your customers is a function of how easy the code is to change. In turn, that ease of changeability is a function of how easy it is to read, maintain, and reason about.
Focusing on "shipping the feature on time and bug-free" is good, but at the extreme it can lead to the mentality of "I'll fix the tech debt later", with "later" being indeterminate. Which is when the old saw about tech debt being like credit card debt starts to bite one in the ass.
Because there is no middle ground, right? It’s either perfect code that will never ship or unmaintainable code that gets shit done.
Besides if you let “we’ll fix it later” take hold, you eventually end up shipping features after the heat death of the universe while also having unmaintainable code. The best of both worlds.
> There are a lot of formulas on how to do estimates, and everyone has their own rules. I also have my own rules.
The actual way to produce estimates can be found in the excellent book Thinking Fast and Slow by Daniel Kahneman: you have to consider a previous project (or, better, several of them) of roughly similar in size and scope, and use that as an anchor for this estimate. You're allowed to add or remove a bit because of a slight difference in complexity. But the golden rule is never to say that this other project doesn't count because, although it seemed similar at the start, it encountered unexpected problems. That's the whole point!
If you haven't worked on a project that large (or kept good enough notes about how long it took), well, tough luck, you can't produce an estimate, any more than someone who doesn't know any software dev at all can.
Looking back at a project with this in mind I was surprised to find the distribution of subtasks (into 3 big buckets of "main complex logic", "simple GUI", "reports/presentations") was roughly equal rather than about 80% on the first one as I suspected. There's no way a rule like "add 40%" can help you with something like that.
The book discusses a great example where they were preparing a university syllabus to teach various biases, including the underestimate bias and this very technique to avoid it, and they still underestimated how long it would take to prepare the course (even after being given information about how long previous courses took to prepare!).
Another recommendation in the same vein is How To Measure Anything by Douglas Hubbard. And Superforecasting by Tetlock. Estimation/forecasting (same thing different emphasis) is a problem we know quite a lot about, and we know how to train people to issue calibrated estimations.
I mostly agree with the points but I hard disagree with point number 3.
Clean code makes the project more easily maintainable. We generally try to keep a standard in code quality (and I would say 98% of the codebase we touch is well written). We also try to schedule refactoring rounds (but that doesn't always happen because of time constraints).
That isn't true either though. Sure, they don't care about it as a first order thing, but they care about development not slowly grinding to a halt over time. And writing well structured code is one of the things the software side of the house does in order to do a better job delivering on that desire from the business. If nobody on the technical side has the credibility or trust to make that case, then that's a problem.
>Sure, they don't care about it as a first order thing, but they care about development not slowly grinding to a halt over time.
Most only care when it affects them or sales, not when devs are asking to allot time to clean up code or pushing off a release to fix wonky stuff. In my mind that's not caring.
That's like people care that they can't walk up stairs without huffing and puffing, but not enough to actually diet and exercise. That's not actually caring, that's really regret.
I'm fortunate though, my company gives a lot of credence to dev.
That situation sounds to me like the problem of the development org not being trusted by the company's leadership when they say "this will slow down short-term initiatives but speed up long-term ones".
Yes, it's pretty common in my experience. Of course executive bonuses are granted based on short-term initiatives more so than long-term ones. When they finally reap what the sow, just blame dev. You don't get to be an executive without knowing how to politic.
> Don't get me wrong, people will expect you to write good and clean code.
I can agree with this. Clean code is not "celebrated" because it is expected as normal. You won't get a raise for it. You could get problems for not writing clean. But when the business gets into a tight spot, they will accept shitty code that fulfills their desired goal over a nice clean and elegant solution delivered few days later. In this case, the shitty code could get you a raise.
There are different problems in different orgs with different value adds. You can be super busy firefighting for a company that doesn't value your work or calm, well-paid but unchallenged in another.
Also the same general pattern of learn -> earn -> own applies in tech.
Learn your trade, milk it for a number of years to setup your life, own your own consultancy/company.
I skimmed the bullets and pretty much agree with all of them. I’ve been doing software dev for 25 years or so so have been around the block a few times. There’s a lot of good to go with the bad though, sometimes you meet incredible people who you just stand in awe of and other times you get to have a huge impact on someone and get to watch them blossom into something great.
But yeah, the most painful is you rarely get a greenfield project, most of the time you’re bolting on features to a shotgun shack of a codebase and praying for the best.
> sometimes you meet incredible people who you just stand in awe of and other times you get to have a huge impact on someone and get to watch them blossom into something great.
i can verify this was my experience at my last startup!
The soft skills section has some great examples of where the author lacks his/her own soft skills.
Some folks, during stand up, just want to get on with their day. They will say things (Like George Did, "I helped so and so all day") just to keep it moving. Doesn't mean they truly believe what they just said, they just want to get back to work.
Sometimes, people will do things, things that seem like they are incompetent or don't care, but really that is your own bias (Why did they not help me when I needed it?) and make you look like not the team player. Instead, you should have gone to "George" and said, "Hey, thanks for looking at that issue, I managed to solve it with Michael's help, here's how we fixed it." Lead by example. Lead with empathy. Maybe George spent only 5 minutes with you because he has deadlines and doesn't have the communication skills to say "Hey Bob, I'd love to help you, really I would, but I have this hard deadline for this feature I'm working on and it's stressing me out because I can't solve this edge case". Use your words, explain your thoughts, people will be WAY more receptive and will want to work with you. Again and again.
If you're a junior dev, I'd urge you consider that there is a difference between software engineering and the digital factory. The author seems to work in the latter.
IME, the people who say such things as "college won't prepare you for the job" or "CS doesn't matter" are invariably the ones who find themselves grinding away at REST endpoints and becoming embittered.
College absolutely does not prepare you for any software job, unless you are some kind of ivory tower architect that can tinker in a lab with no need to ship products or work with other teams.
There are few things more practical than a good theoretical grounding when your job is to:
1. design and implement a database
2. design and implement a p2p consensus protocol
3. design and implement a programming language
4. train and validate an artificial neural network
5. reason about concurrency
etc.
At some point, we really need to start distinguishing the kind of programmer who writes REST endpoints all day from the one who engineers the systems other programmers treat as an abstraction. Both are respectable jobs, but the former is closer to plumbing than engineering. The former is also less well-paid, has less job security, more on-call duty, less intellectual substance, less technological innovation (but arguably more commercial innovation), more grunt-work and a lower barrier-to-entry.
OK, 99% of devs do not do items 1-3. I have never worked at a FAANG, but most of them are doing grunt work, from what I have read.
Furthermore, taking a database course in college might involve building a toy DB, I will argue that it is not at all comparable to building a new DB from scratch. The theory is helpful, of course, but it is just an introduction, unless they are doing serious post-grad research.
And it isn't just "plumbing" jobs like REST. The same thing was true when I worked in game development, or consumer apps. Back in the 90s we did have to occasionally write a new data structure or something, now it is off the shelf.
Now please consider this: the reason why so many devs are disenchanted is because they are being told that the software industry is like that 1%, when in fact, 99% of it isn't.
With this in mind, perhaps we should teach people about this "software engineering" vs "software plumbing" distinction. I suspect we are doing a bad job of orienting young professionals because of some outdated status hierarchy such that "engineering is for nobles" and "plumbing is for the pleb", which leads us to present software engineering as the ideal to strive for. Rather, we should identify the people who show an appetite for the noble profession of plumbing and steer them in that direction. While we're at it, we can paint a more realistic picture of their economic prospects, job security, work-life balance, etc.
There is no need turn this into yet another theory-vs-practice debate. That's a false dilemma. The best work gets done when both players collaborate.
When I was in college, I just wanted to build stuff, ideally games, but whatever was fine. I had no illusions that I would be writing compilers, writing OSes or building chips, even though I took courses on those subjects. A lot of the course catalog was on esoteric theory, like proving theorems, lambda calculus, early 80s cellular automata (what we called Huffmanetics, as Huffman taught those classes); I avoided those classes like the plague, although it was kind of dumb in hindsight. I wish I had studied more math and theory...
What they did not teach was how to code. You were just expected to learn that as needed on your own. What I needed perhaps was some kind of engineering major, as opposed to computer science, but that wasn't available at my college at that time. And even if it was, it wouldn't really have taught us how to be a professional developer, it would have just given us an overview of various topics.
Maybe you are arguing that we need such a program? I'm not sure. "How to be a professional programmer" courses do exist, at boot camps. People here on HN don't seem to think they are a good idea though.
> Maybe you are arguing that we need such a program?
Yes. I’m arguing that there should be some appropriate path for people like you, and that path doesn’t have to take the form of a college degree. Note that I wouldn’t object to it taking the form of a college degree either. I am agnostic.
In terms of being relatively accessible, well paid, safe, interesting work software engineering is probably one of the best jobs ever in the history of humanity.
Yes there are downsides, but IMO they are relatively minor and pretty similar to what people in any other field experience - incompetence from coworkers, office politics, too much time talking and not doing, and the concern for the bottom line of some ideal of perfection or craftsmanship. In addition, for most jobs that require college, what you learn in college is only the foundation and you will need to learn a lot on the job (see for example residency for doctors, flight hours for pilots, clerking for lawyers, etc)
In exchange, you get a relatively well paid job that only requires a 4 year degree (if that) to land an entry level job. There is a vast opportunity for increase in pay either through experience or starting your own company. In addition, if you want to start your own company, it is one of the easiest fields with much smaller regulatory and capital requirements compared to almost anything else.
It is not just well-paid work, it is interesting work. Lots of people, including me, find software engineering fun and fulfilling. There is just something amazing about creating something cool. Many of us like this so much, we have non-work side programming projects of our own.
Software engineering also offers some of the best work-life balance potential of almost any high paying field.
And again, compared to other high paying professions, it is much easier to get into. Although people complain about interviews, they are less stressful than trying to get into medical school or law school and there are a lot more entry level programming jobs than medical school and law school headcount. It is also much more accessible than anything in entertainment or media.
So in summary, like everything else in life, it is not perfect. However, currently, it is one of the best, most accessible careers, possibly in the history of human civilization.
Without knowing the exact expectations of the people the author spoke to, I'd imagine lots of the misconceptions are on-point.
One personal exception for me was how university (not college) prepared me for my future in software engineering. The courses I took quite often involved group projects of 2-3 people completing work cooperatively. Undoubtedly this was - by far - one of the best and closest to real-work experiences I had during my earlier education.
Compromise, discussion, division of labor, and a healthy bit of experience with individuals who'd prefer to be part of the project credits but ideally do as little of the work as possible.
Here's another good one. You almost certainly will never make it to the upper class with this career, no matter how well you perform, unless you transition to management and climb to VP+ in a large company or start your own company. You can be comfortable as an engineer, but it's not the gold mine lots of folks think it is.
> Sometimes you don't know the whole story. I have seen some cases where a person just can't do their job properly. They are burdened with tons of tasks and doing work for 2 people.
Never mind people who are just starting out -- I think many people on HN could really benefit from this perspective.
I had 20 years in industry from tiny startups to megacorps, W2 and contractor. Now I'm an instructor at a state university. So I've seen all sides. :)
Re point 1, you'll learn a lot in the first few months in your job. The old adage that you'll learn more in the first 6 months on the job than you did in all of college has been around at least since I graduated nearly 30 years ago, and almost surely existed for decades before that.
But you can't spend four years learning to learn and have zero impact from that. If you got through college and the only thing you have to show for it is a diploma, you didn't do it right.
The author is correct that it's not everything you need. But it's only four years and it's tough to prepare a student for every single possible work environment on the planet. The only real option is a foundation, and they pick up the rest using their learning skills when they hit real life.
Also, re "So don't get overly attached to your clean and elegant code. Focus on shipping the feature on time and bug-free." There's an interplay between all these concepts that I don't think the author acknowledges.
Future maintainers, who could be you. It has happened to me a few times, and I thanked my past self every time.
It doesn't even have to be clean code. Sometimes I'll even settle for understandable code. In my experience, however, few people care about this. My most common comment in code review is "add doc" or "add explanation"
True. But you should also write it for your fellow developers/engineers. If the culture among engineers in your job discounts the value of clean code, you're probably entering a world of pain.
Sure, you should not obsess over clean code, as it does not directly produce value. You should also not expect your manager to understand its value. But if your fellow engineers frown upon efforts to improve code quality, start looking for your next job. The mental drain is just not worth it.
Esentially, where the clean code is appreciated, mediocre engineers/developers will eventualy acquire "guru" status, just because they happened to be hired a year or two earlier than the better ones. And will often be unfriendly to anyone "threatening" their status.
Technically true. But the user knows when code is in a poor state. A poor C codebase in a security critical area users will find out about. It will crash, need critically patching all the time etc.
If a game engine has a messy code base (Say, they have two slightly different renderering subsystems which makes things clumsy) then people will notice because the games will be late, buggy, cancelled whatever.
For most users though it's that the software is slow, costly, buggy, doesn't get new features quickly and so on. And you can't really tell the reason why. But users DO notice it. Managers certainly notice it. Any manager should recognize a situation where you spend 80% of your time on bugs/regressions, while new features get less time, and take much longer than aticipated to implement. And any manager should instantly recognize that this is invariably due to a poor-looking codebase. Not poor communication, not (other than indirectly) because of bad developers, not poor tools, not anything else. Just messy code.
These aren't hard to swallow at all - how about this:
Good requirements do not exist -
Writing good requirements is months of work -you have to interview business stake holders, ask challanging questions, you ahve to involve industry experts and have developers think, not code.
Its safe to say this almost never happens.
Agile is an insidious ruse - its popular because it frees management from having to commit to planning and discovering requirements. However management still expects engineers to provide them outputs of waterfall - accurate estimates, architecture, etc.
CV driven Architecture is common
Engineers have a complexity addiction and feel inadequate and impotent if they are 'just building' something simple.
So simple projects get bloated to inckude Kafka, kubernetes or some other buzzword of the year. Instead of discussing business problems and missing requirements, engineers prefer to discuss technical complexity. So they often commit to adding technical complexity before they've understood business complexity.
Then when they hit business conolexity, they have no mental capscity or bandwidth left to address it
Communication between business and Eng is usually broken
To arrive at good design decisions, one person needs to have great understanding of business and technology. In most projects, this person does not exist. Design is riddled with qeustions like 'Do we really need to have feature X, it doubles complexity but only 5% of users would even care". To even understand that, business needs to communicate commercial information to developers, or developers have to educate business. This rarely happens, and so these decisions are usually not even identified
> "This may be a shock for some new folks, but it makes perfect sense. As a software engineer, your primary task is to generate value for users. Writing code is just a step that accomplishes that goal."
No other engineering discipline thinks this way. An aviation engineer's primary concerns are that the thing they're building is (1) safe and (2) efficient. Whether or not that product is profitable will depend on marketing and competition at a whole other level. It's NOT the engineer's primary concern. This is also true for electrical, chemical, civil, etc. engineering.
If there are a lot of software engineers that think this way, all that means is that the discipline is still in its infancy and hasn't adopted the kind of engineering standards that others have had to over time. Maybe the kinds of standards and regulations applied to sellers of electrical devices should be applied to every company that sells software?
> Meetings are an important part of the software development job.
Imagine the folks building the Linux kernel or other popular, successul, and mission critical software projects sitting in meetings all day long.
I genuinely think that meetings are the only way management can justify their existance and therefore commercial projects consider them as an "important part".
>> I genuinely think that meetings are the only way management can justify their existance and therefore commercial projects consider them as an "important part".
reply
Wait until you join management at some point in your career.
I did. And held few and to the point meetings. I could see how non technical managers were struggling, and that’s how i know that some are simply clueless and serve no purpose within orgs. I managed a somewhat small number of devs - roughly 40, some distributed.
I think college prepared me for some of those things.
Group projects were a standard thing throughout most of my time there and they introduce you to the messiness of teamwork.
I still recall one semester during which I was in two group projects with another guy and we negotiated who'll be slacking off and who pulling their weight in each of them so that everyone passes.
One friend of mine is still holding a grudge against a mutual friend of ours who was extending the deadlines given to him to deliver his part until it was too late.
I got top marks in a project where two guys just took over seeing that me and the forth guy were incompetent.
I took one for the team when our lecturer said that he won't be giving top marks to everyone, so we need to decide who loses 20% of their points - I volunteered because I knew he personally disliked my choice of technology (NodeJS - we had complete freedom in that project with regards to platform/language) and I just needed to pass.
There's one source of bugs that the author doesn't mention: time, and how our understanding shifts with it.
Sometimes the understanding of what a business object (or one of its attributes) represents sometimes shifts, over the course of several years. Sometimes, that shift is suble and easy to miss, like that it used to represent a desired state, and now more often represents an observed state.
Sometimes, other ways to manage some objects come about, and of the original use cases of an object or table, only some (formerly niche) use case remains.
Sometimes our use of language drifts, for example when a third-party tool is introduced that uses similar but not-quite-identical vocabulary.
All of these can lead to formerly correct behavior now being obviously wrong. Sometimes it's hard to remember the context of the original implementation, and you ask yourself why anybody in their right mind would have done what you did back then.
- stay humble. you are inherently no better than the guy who cleans the floors, even if you are paid more
- your benefits package may rise very rapidly but it will hit a plateau unless you begin caring deeply about a domain other than mere software. You will need to start getting serious about something like finance, healthcare, automotive, etc
9 -
I’ve been doing this so long and this gets harder and harder. I’m at the point I’m so severely burned out I’m planning early retirement to get out of this industry all together.
For me what makes it even more worse is I didn’t get into this field until I was in my 30s. Beforehand I drove a forklift in a warehouse, I was in the military, then an electrician, and finally a electronics repair tech afterwards. Those fields the disconnect was passive, didn’t even have to think about it.
Software you have to jump through mental hoops to remove yourself and that’s just as exhausting as the job itself.
I dream of a job working at a garden center or maybe driving a forklift again. This field sucks.
I was lucky to figure this out before it was too late. I was studying for CS masters and worked as a software developer for ten or so years from quite a young age and started noticing I hate most of it, and it was just getting worse.
I love programming, but vast majority of software development isn't programming even if you work as a "programmer". It's a constant bureaucatic fight with piles of horrible codebases and technologies and bad ideas (that aren't even yours).
I switched to academia and now I actually get paid to program. Not ridiculously like most white collars, but still unreasonably.
And I don't have to turn into a badly fitting mindless cog for the prime hours of my life.
While many points are true (but IMO not all) I would not see all of them in a negative light. Especially for a new grad just starting in the field.
For example, yes, you will likely work with existing codebases, but in most other professions you will work within established constraints, not all of which are fun, etc.
On the flip side, a good knowledge of software engineering offers excellent money and opens a lot of doors. Want to live and work in Europe for a few years? Take 3 months (unpaid) off to surf and recharge? Negotiate remote options? A good software engineer is likely to manage those with some negotiation and planning. Not many other professions would allow that today. My 2c.
I dodged all of this hard by taking an interview with a smaller engineering-adjacent company. A lot of these points seem like the reality when working at a gigantic conglomerate that doesn't take its software arm very seriously. Mine does because the software analysis is the core product.
1) All of my previous practice and my Master's-level statistics and signals processing prepared me well for this job.
2) Out of the gate, my boss gave me free reign to greenfield replace a lot of old tools.
3) My clean code and the documentation around it is needed, because obfuscated and undocumented code is what previously shot this company in the foot, and is what I was replacing.
4) Everyone in the software part of the company is competent; the only issues come from outside our department.
5) We have one one-hour weekly meeting to talk progress and potentially connect on important points. Everything else we discuss as needed.
6) Estimates are rarely needed because I made the right choice of languages and tools. I can make changes or add features same-day or within a couple days. One longer-term project I'm on has no deadline; it's needed, but not urgently.
7) My choice of language and tools makes bugs easy to track down. Most of my issues are solving for engineering edge cases.
8) Not that I'm always certain, but uncertainty is never really an issue here.
9) I hard disconnect from my job, and my boss wants it that way. Nobody has my email or phone number. When I go home, I go home.
10) I've had soft skills my whole life, so I've never run into that issue.
I didn't get the fabled six-figure starting salaries people everywhere seem to be chasing, but I've concluded those aren't truly real and were driven by $2 trillion money-printing valuations.
If anyone is curious about my tools, I use Nim to analyze signal data and output analysis and reports; it's a CLI tool that puts out standardized data formats, which can be invoked by server scripts whenever needed. Most of our systems have already been overhauled to use it as the crux of our data analysis. I replaced a lot of old deliberately obfuscated C and PHP.
I've been in the game a long time and there is not much here I would disagree with.
"Working in software engineering often means long working hours. Most of the time, you are glued to a computer screen, with little work-life balance."
For sure this is true. The younger you are, the easier it is to deal with and be amazingly productive.
As you get older, life creeps back in and you get a bit of balance.
When you get to my age it becomes less about screentime and more about problem solving. Something I am very happy about.
Eh that's one of the least universal ones in there. I've worked in tech for a decade now across 6 positions in 4 companies and I have never had any complaints about WLB. If anything, I frequently feel like I'm getting away with something when it comes to how little I can actually get by with doing if I want to.
11. Perception is reality. Ideas mean nothing if you can't sell them. Providing actual value to the company means nothing if you can't sell it. You will work with people who cause more damage to the company than they bring benefit but are good at selling it. It does not matter what you think about what you are doing, it only matters what other people think. If you can be good technically and be a good communicator, the world is your oyster.
12. Most developers are very wrong about what would bring value to their managers. If you think you are underappreciated for your good work, there might be potentially very simple things that you could change that you aren't aware that could make you much more successful. Your manager might care less about how elegant your solution is but might remember you were two days late with it because he had to explain to his boss why the entire feature got delayed. Every situation is different and there is nobody on your team to help you -- you are responsible for reading the situation and making what is important.
--
And regarding:
> 10) You will profit more from good soft skills than from good technical skills
I would add more. You will profit more from learning an orthogonal skill or field. You can be good developer by just being able to gather requirements and implement them. But you can be extremely valuable, sought after specialist if you know how to do those things AND ALSO know some other field not commonly considered by developers.
Oh, agreed on that. I would say doing what your manager needs rather than what he/she asks you to do is a senior-level trick. You need to be experienced to be able to pull it off successfully.
The problem with time estimates is that you often have to estimate not what to do but a vague vision of something. We want it to be easier to do X. How many hours?
I agree with what to promise. The problem here is that you will get pressured into bad decisions. Somebody might say that it's just a new button. It is never just a new button.
The joke, junior devs work with coding, senior devs with people is true. Many coders quit coding after some years and go full time into management positions. At some companies that is expected and you are being looked down upon if you are "still" coding.
Clean code does not really tell if a solution has good architecture. I have seen horrible solutions that use clean code and great solutions that have mediocre code.
Management typical just want new features. Prepare to be called in to help resolve issues related to bugs that has been known for months but not been prioritized.
Third-party companies are not your friends. Be prepare to work with people that will straight up lie about things. Also be prepare to work with colleagues that does the same thing.
People will try to take credit for your work. Management people are experts in this field.
But the worst thing is also the best thing about being a coder. You have to to keep up and learn new things. The biz is crazy fast. It is easy to challenge yourself. The amount of new cool stuff coming out is just amazing.
In the words of Terry Pratchett, "It’s indoor work with no heavy lifting". And it pays astonishingly well. Which are useful things to remember when it sucks a bit.
There is more nuance to this. Soft engs need to realize what stage of product and business lifecycle they are working on. Most importantly, get into the mindset individual contributor not just a programmer [1] (highly recommend reading Patricks blog on this)
1. If you're building 0 -> 1, the focus is shipping early and faster. This is not the time to crib about SLOs and chaos testing. I'm not saying these things are not important, but very likely they are way down the list.
2. Once you have crossed the chasm and have a mature product or platform that product engineers rely on. Then reliability, fault tolerance SLOs etc matter a lot more. This is the phase, I'm more concerned about using the right abstractions and ensure tech debt is managed well.
3. Product is in KTLO mode - In this phase, you could probably spend quarters LARPing on making things better and afford to work on things that very likely have diminishing returns.
Nobody gives an eff about your clean code, if no customers are using it.
The time you spend on projects is, according to what the PM tells sales, two weeks for a feature and three weeks for bare minimum requirements new product. Outside of that your own company will guilt you into some feeling of inverse wage theft where you make up for it by donating your free time. Realistically, three months to build an app you can demo is tight but those are competitive timelines and you want to be competitive don’t you? AI I’m sure has skewed this towards less effort to meet those timelines (I hope). Another hard to swallow truth is that sometimes you are just given a project there is no optimal solution for because you were meant to fail at it. Usually it’s a problem client or impossible task. The more skilled you are the more likely it gets assigned to you. Developers that get to cherry-pick all of their assignments are also the ones that get to lie about their time allocations on projects (to add insult to injury). If you are a new hire you will be doing a lot of their work for them so climbing up the ladder takes a lot of humility. Most devs super concerned about other people’s mistakes usually cause a ton of problems themselves and this concern is directly related to all the things they are actually hiding/covering up in reality. It’s not uncommon to find that the Super Saiyan coder is actually keeping a proverbial building from falling down with a toothpick but they are very concerned about the formatting of everybody’s code. Younger developers think, by default, everything is crap but they don’t even bother to hide any of their screwups and they have the energy to keep screwing up for a long time and at an accelerated pace. This, ironically, does mean more money for the company so hiring a lot of young developers is good for the bottom line and makes customers seem very engaged.
I don't think the learning how to swim analogy is good. Where I live it's mandatory for children aged 5 and above to take swimming lessons and to test out at some point. So, there's a lot of involvement with this subject.
Anyways. Theoretical part helps. Doesn't guarantee that you learn how to swim, but is a necessary component for you to learn well. College CS education is just outright harmful. Not only does it not give you practical knowledge, a lot of what is being taught is outright wrong. If we stretch the allegory of swimming lessons, it would be like if in these lessons, while only teaching the theory, the instructor told you that breathing underwater is possible, if you try hard enough, or that diving and landing flat on your belly is the way to dive.
Another aspect that I find really upsetting about college CS education is that it focuses on inconsequential, transient issues, at the same time completely ignoring important ones, and, at the same time, not investing any effort into trying to systematize knowledge. There's very little effort (or non whatsoever) put into building advanced concepts from first principles. Often times links necessary to connect several concepts are missing and the students aren't even told that these concepts are somehow related, or even if they are, then there's "magic" in derivation which is never explained. A typical example would be how in automata theory the course usually ends with building some very simple programs using Turing machine, and the closest next link in understanding programming languages is learning some modern elaborate programming language like C or Python.
College CS education is way overdue for a fundamental revision, and I wish CS had its own Bourbaki...
> 10) You will profit more from good soft skills than from good technical skills
Related to this, your customer is not the company's customer, it's your management chain. It took me an embarrassingly long time to internalize this. The stories executives and managers tell each other is what decides you career trajectory. What is their priority and how will they judge the outcome?
> your customer is not the company's customer, it's your management chain
Another: some coworkers will have spent so long in large corporations that they've internalized the pathological dynamics of large organizations as universal truths.
Your customer isn't going to decide salaries, promotions, or who gets laid off. Here's your universal truth: focus on the person whose decision affects your outcome. If you work for people that will see and reward your focus on the user, that's great, keep it up.
no, it will not, it has a completely different role, the other name "University" gives you a very strong hint about it: what you learn in university is a universal way of thinking, of acquiring knowledge. The dirty secret is it doesn't matter at all whether you learn this by studying human anatomy or the stars blinking above. By the time you leave aside from very basic stuff your specific knowledge will be outdated anyways for multiple reasons. And your assignments are irrelevant to any job you will take, the primary criteria for your teacher when choosing assignments is the ability to grade you fairly and easily on a task with a known complexity.
And there's no fast way to do this. We do not know how. There are a few, extremely few people who seem to be born with a mind honed to this but most people are not Terence Tao :D and actually need the five years of university to get there.
> Working in software engineering often means long working hours. Most of the time, you are glued to a computer screen, with little work-life balance.
> The job demands an online presence, sometimes even after work hours. This often leads to stress and limited personal time.
Maybe in the US. But in France, where I live, it is absolutely not the case. You may have long working hours if that's your thing or if you are working in a particularly toxic company. But most people I know just disconnect outside of work hours, this is even protected by law. Before the pandemic, in many cases you simply couldn't work after hours as you weren't allowed to take your stuff back home and the office was closed.
The drawback of being a software engineer in France is that the pay is much lower than in the US, by all metrics.
For the rest of the article, I think it is accurate.
In the US it varies between companies, but it’s not all that difficult to avoid places that expect extra overtime, or to say “no” when it’s requested in most cases. Eventually they stop asking you, ime. I’m unsure whether declining has a negative impact on one’s career.
If only I had known that one earlier. I was fortunate enough to work only on greenfield projects for my first fifteen years as a software engineer. However, at some point, I was brought into a brownfield project [1] for maintenance, support, and bug fixes.
The difficult part was not related to things like clean code, architecture, and so on, but to the lack of consistent thought processes around the choices made, as well as the fact that there is a lot of tacit knowledge in people's heads that aren't documented, and how arbitrary convoluted things can be, especially if foliks wants to ensure their own employability through manufactured complexity.
It took me at least three years to realize that new technology is the exception rather than the rule.
[1] - Brownfield project it's something that has something green still but starts to be muddy and swampy.
Bugs?!!! Some good ones sure but I don't understand "Bugs will be your arch-enemy for life". Bugs can't be your enemy. Bugs are what you do. It's your life. We are talking software engineering. If you hate bugs. If bugs make your skin crawl. If you throw up or throw monitors out the window... Then please don't get into software engineering! Or at least first look at yourself and recognize that this is why you get the big bucks. Sorting out bugs is normal. The time it takes is normal (well, do get better as you go about it...) You get paid for that. People rely on YOU sorting that out. Bugs are not the enemy. Bugs are the job. Get yourself to a point where bugs are not the enemy. You can't spend your life getting frustrated by bugs.
Great list. Ten years in, I have to say I completely disagree with #6 though. My 2c, never give estimates. They are a trap.
As a developer, if you give an estimate, it will be questioned, second guessed, and then negotiated down to 1/3rd of its former self. Then when you do the work, it always takes twice as long as your original estimate. The whole dance of estimation only succeeds to indoctrinate developers into the political environment of the organization, it turns developers into mini-managers over their own time and perturbs their productivity.
Software engineering as a discipline has to move away from developer estimates. If you’re articulating the work that needs to be done, estimating the work, then doing the work, the only function of your boss is to report on your execution. The demand for developer estimates are a consequence of managers trying to turn themselves into highly paid messengers with no skin in the game. I’ve seen what that does to developers: late hours and weekend work, horrible diet, stress, weight gain, divorces, it’s ugly stuff. Don’t let it happen to you.
Have your boss make the estimates. They have access to resources you do not have. They can look at past performance on similar projects, they can look at actuals. That’s their job. They need to do it.
If they ask you for an estimate, “how long would it take to do x?” never start by saying “it would take about …”. Ask a question, something like “what do you mean by x?” Or “have you considered y, is that something we should be concerned about?” etc. keep doing that until you’ve gotten your boss to the edge of their knowledge. How they react will be telling. You end up providing more value in the long run because instead of giving your leadership a false sense of security, you’ll be educating them about execution risk and setting your projects up for success by setting up future conversations to be constructive. If you do fall behind, you have ammunition to fall back on in meetings “last month I asked about x, because I was concerned, and now that concern has come up.”
This is a pretty good article and I suspect a lot of it applies to almost any job. Replace software engineering with accounting or electrical engineering or whatever and it's probably all still true. Working with other people can be difficult, soft skills and kindness are what make it less difficult. Find places where the culture is a good fit for you and where the interviews focus heavily on behavior.
Also, work on yourself. There's a lot of toxic attitude in this post and even more so in these comments. Stones and glas houses come to mind.
You don't have to be apathetic in response to the realization that politics is a major thing at higher levels in bigger organizations or that estimates will almost always be wrong. That's like not enjoying sunny days because eventually there will be bad weather. Very silly.
I disagree about the clean code. It’s what defines engineering vs ‘mere development’.
Spending time on design up front and doing the smallest thing that could possibly work allowed you to move very quickly later.
THAT gets noticed by management, and if you preach it long enough they buy in.
Clean code is nothing more than just making sure a code base is fully consistent in its structure, self similar, or crystalline in its structure. Basically no cowboys or egos allowed: everyone writes things in the same manner and style, so everyone can understand it. It takes a lot of maturity from devs to do this and a lot of code reviews.
I first saw this coding technique on a medical codebase that tested drug interactions, and later on a very much ununamed defense code base.
Whatever the standards are ends up being s bit arbitrary, the actual value is ‘everyone does one thing’.
The points in this article match what's in the book "Poems for Software Developers". https://www.amazon.com/dp/B0CMNR4G39 Like the article says, you'll probably not get a greenfield projects, you are going to spend a lot of times in meetings, and you aren't going to just be left alone to code. You will have to work with people on a team. Knowing the technical aspects of programming is one challenge, but another challenge is coordinating the effort of developers to drive to a goal, on time, and according to requirements. That coordination effort is a lot of what the experience working as a software developer is all about.
11). Despite excitement and encouragement to learn, after 10 years of learning, staying employed at the same salary level becomes harder, not easier. :)
There are outliers... but I would say on average ageism hits most of us. Being a specialist is a must at that point (if you want $$$).
Mostly agree, but i think the more seniority you get in your company the less you will deal with these issues and of course changing jobs helps. So basically you might encounter all of these but not necessarily.
And starting from scratch and college is basically the same point
There’s some good points on here that I might share with some tutoring students, esp about greenfield and how that’s really a coveted thing in a social setting of engineers. I do think the tone should be worked on so it is less.. bleak. Like, I don’t really remember being nervous about how long something would take me, unless I was concerned it was impossible to do to begin with. I also didn’t have to deal with thinking about the job all the time, because I was doing it, which is a tongue and cheek way of saying if you want to succeed, work life balance might look different to you than to the peer next to you.
Absolutely false. And you'll know this as soon as you need to change or maintain your own code.
Even if you're a purely cynical person who does not care about your team members, or the future developers (and you're just optimising for business outcomes) you have the incentive to save yourself a lot of pain, as well as embarrassment when customers ask you for something and you need to say no.
I would, at minimum, rephrase that point to "Do clean code for you (and for your colleagues), not for some abstract virtue of writing clean code"
A less charitable interpretation is that "Nobody gives a f* about your clean code, because if you're dealing with code, you're a nobody in the business"
I take issue with #3. The clean code is for you. Future you. You will be substantially more productive if your code is clean. You will end up being the "rockstar" (groan) because you can implement 2, 3, 5, 10(!) times faster on your clean code than your peers. I am living proof of this. And then when your managers and company realize you're the cash cow you can ask for absurd raises and get them. You are going to be hard pressed to do this with crappy code bases.
And in my experience it isn't true that nobody in leadership appreciates this. I think it's easy to make the case that it is worth investing today to make it less burdensome for a team in the future, which may or may not contain the current team members, to evolve the software being written in the moment. This makes sense to everyone in a business, because the same is true of any business process.
"Clean code" is not the only way to accomplish this; processes and documentation are other things you can do. But I also think it's easy to make the case that writing comprehensible code actually has the best lifetime return on investment. It isn't hard to do - indeed, it's often easier to ship working features with well-structured code, and it requires less future toil than documenting a process that requires working around poorly structured code.
But of course often times there is a tipping point where further tinkering with making code "clean" is no longer net positive. But I think codenames that tend toward I dunno, maybe 95% cleanliness provide good value to an organization.
I think the point with regards to clean code is somewhat changing. As companies and their clients adopt process certifications such as ISAE, static code analysis reporting is slowly becoming a requirement for the release process, driving measured code quality improvement and directly tying it to business outcomes. I feel like some other points are also less severe in technology oriented companies focused on cloud native, continuous delivery and that manage based on the DORA metrics.
I couldn't agree more with this list.
While I was at university,I used to imagine software engineering job like a place where like minded people talked all the time about algorithms,new technologies etc. A place where senior engineers would guide/mentor you, where you could take time to create the best code/solutions... :D
For me, discovering that soft skills often are more valuable than tech skills was a huge wake up call.
This actually describes the job pretty well in my opinion, as someone who has been in this field for over a decade now. Not everybody is cut out to be a software engineer, and the "day in the life of" youtube videos where they never do any work and just eat all day of free food and socialize just paint an inaccurate picture of reality, making the job seem a lot more glamorous and easy than it is.
> It's just an empty protocol to prove their purpose of existence in the company.
Sounds like he came from a pretty bad development environment. I am sad to think this is what he communicated to young developers.
These meetings can help to surface problems, provide a shared space to refine work as a team, create a plan against available resources... All of this helps developers move faster and ship more frequently.
RE estimates it’s not about the time selected, it’s about managing expectations. People need to know what they can expect from others in order to collaborate, the skill is in knowing when and how to communicate in the framework you’re working in, so that everyone you’re working with has reasonable expectations. You can get it wrong plenty so long as you manage people’s expectations well.
I feel like Cal Poly SLO prepped me for “real programming” relatively well. The software engineering major has a year long capstone program building software for a real company. I built a scriptable GPS emulator for Trimble. I was also required to do a work study to use software engineering to the benefit of someone other than software engineers (I worked on real estate).
My degree was in computer engineering, not software, so when I started out, I got into QA/Testing. Looking back, that was a good way to start in the field because you're thrown into a shallow end of the pool and it allows you to feel your way into the deep end.
Mobile development back in 2010-2014 is just full of greenfield projects and I am just so lucky to be part of it. Every month it feels like someone has a great idea of an app.
There were no reviews back then in Play Store (formerly named Android Market), same with iOS, app store does not yet had a very strict review.
Most problems today stem from scale?
A big org of with 100% non technical people and 100% technical people where the sweet spot was the small game studio from 25 years ago, nerds, but social, tightly knit, experts but generalists because of size, close to each other, and pretty small.
>>If I need to deliver some feature, and I think it will take 2 days, I add roughly 40% more time to it
My first real job and Dan told me to estimate by first doubling your initial estimate and then multiply by 4. This gives a pretty good estimate, in most cases ...
Approachability and emotional intelligence have been two of my greatest weapons in IT, not my technical skills. Humans are and always will be creatures of emotion, not logic. It sounds corny but I usually strive to be the guy people would enjoy having a beer with.
> You will *profit more* from good soft skills than from good technical skills
The rest of the truths I'm more or less okay with. But this one, no: in large orgs, people with good "soft skills" will profit more *to the detriment of the projects*.
This reads like a person who has walked past a couple of turns in the road from the starting point, and is looking back to describe the totality of a grand journey to the his naive uninitiated inferiors.
#2 and #3 are a bit at odds with each other. I certainly get tired of coming back to the same problematic code that's difficult to read and maintain. I appreciate others (and myself) for writing clean code.
A lot of these are applicable (in the general sense) to jobs in many other industries as well. But I'd still rather be a SWE because the compensation doesn't really compare.
If you are new, and you are asked to estimate something, get your boss (or other mentor) to help you sort out the local customs. Don't throw some random number on the table.
Also, don't get too attached to a project. Get mentally prepared to work on a project for 2 years then have it cancelled. It happens. Get over it. It's not your baby.
The last point is the most important one, last of course, as our industry does not respect communications, despite it being the main cause of all our irrational management deadline issues.
1. Most academic institutions were never intended to subsidize corporate training costs. While this line sometimes gets blurred these days, one must assume you are learning basic skills 80k other people already have.
2. The primary HR issues I’ve seen is a lack of humility, inexperience, and people entering the field for the wrong reasons. Financial motivations are fine and all... but giving a toss about what you do is important in the long term. There is zero correlation between degree level and productivity… Indeed, some kids get by on social media with an army of Googling friends to try and game through challenges (think of a Borg-cube that assimilated a planet of smug morons.)
3. Some people are cultists, and firmly believe success is bestowed on the truly deserving. In some ways they are partially right for a cog-in-a-machine proprietary process position. However, the range of skills needed grow exponentially as the organization shrinks, and rapidly deprecates people not willing to show any initiative.
4. Your work is likely naive garbage at first, and while management doesn’t know any better... your peers do. Expect to be hazed until one can contribute coherent work. Yes, you will be working on projects that match your skill-set, and if you don’t clue in your career will be a short one.
5. Assume you are the dumbest person in the room, and be pleasantly surprised when you are wrong. Some folks have literally met 80k people just like you, and whatever cleverness you think is original... is often just tedium in another perspective.
6. Your loyalty will not be rewarded. The industry will not suddenly develop integrity, but it is rather a personal boundary you choose after seeing peers exploited.
Are these hard to swallow? It feels like the author is pushing a particular tone when stating facts (with maybe a couple debatable points) that any software engineer would agree with.
Sounds like some bitter lessons from some pretty bad workplaces. Not everywhere is this bad, people. Expect to change jobs a few times before you find a good fit.
This is what makes co-op programs so great! They solve problem 1, allowing you to encounter these truths over time in the real world before you graduate.
I don't consider any of these to be 'facts'--I'll save you the click (unless you're curious):
TL;DR
1) College will not prepare you for the job
2) You will rarely get greenfield projects
3) Nobody gives a f*** about your clean code
4) You will sometimes work with incompetent people
5) Get used to being in meetings for hours
6) They will ask you for estimates a lot of times
7) Bugs will be your arch-enemy for life
8) Uncertainty will be your toxic friend
9) It will be almost impossible to disconnect from your job
10) You will profit more from good soft skills than from good technical skills
Conclusion: Software development is not a dream job.
Personally this is still my dream job and has been for 40 years.
The only one that's had any impact was 'incompetent people' (if they're in charge/lead), in which case I've switched teams or companies.
As for (3) or (7) if you value a job well done as do your peers, then it's its own reward and I only care that I'm given (or can make/take) the time to do a better job than management knows is good for the company.
If your worst complaints are that you have to work with others, that solving the problem matters more than how you do it, and you have to sometimes have a pointless meeting, I don’t think any job will work for you. High wages, good conditions, medium social status, high bargaining power, and you get to do something you love. It is the best job available.
as a 20+ year developer, this is excellent. One of the bigger leaps for me (which the author mentions) was going from toy CS assignment projects where I wrote all the code and knew it inside and out to huge multi year projects with hundreds of developers. It was a giant spaghetti code of math heavy C/C++. I was always surprised it worked at all. You don't even know where to start to add some feature (don't panic!). Some highlights where comments above a particularly tricky function was something like: "do not change this, you think you understand it, but, you don't. move along" and something like: "In Graecia antiqua, pueri tui similes in extremis rupibus remanserant mori." (latin for "In ancient Greece, children like you were left on the edge of cliffs to die.")
Sounds very nice. Nobody talks, that highly paid jobs attract all levels of psychopaths. And nobody teaches to work with or under them. Then you go into psychogames asking if I am insane or something wrong with this workplace. If you’re lucky - you leave early and healthy. If not - end in some fancy mental health clinic.
Already mentioned layoffs. My older colleagues went through these too. But really only when the company was going bankrupt. We have now lifestyle layoff rounds to prepare companies for future challenges. Some dude in completely healthy and profitable company decides to throw away 5% or 7%. Job security is gone. At the end you’re a row in payroll’s excel.
> You have to put in extra work while you are in college. Code more projects besides homework and seminars. Do some volunteering. Learn about business domains to prepare for the job that awaits you.
lol yeah, or you do not do this and just get paid to learn all this shit on the job.
The thing that struck me was that the points would ring true for virtually any profession. Yet most young people migrate the transition into the working world OK, and even thrive.
The one unique thing about coding might be the intractable problem of estimation.
I think I’m one of those professors that actually do try to stay (somewhat) up to date with what the industry is doing. Sadly, the SE industry in my area (mostly consulting companies) isn’t keeping up to date, so they complain why we don’t teach our students C#.
Using C# is staying up-to-date (because it is by far the best language if you want to be able to go both high and low level with terse syntax, and it runs everywhere too).
This article restated a lot of the downsides of being a "software engineer", but the real highlight was the cartoon. "How many duck size horses are you willing to fight" LOFLMAO
I'd just like to comment on these points on a 30 year perspective...
Point 4 - incompetent people. They are great. When they fuck up, which they do often, you can save the day by simply being average. Just make sure people know that you saved it.
Point 5 - meetings are great if remote. You can sit there muted on a zoom call for hours tweaking with your bike or playing games on your other computer.
Point 6 - estimates are always wrong so don't put too much effort into it. What people value is how long you spend making up lies so spend some time on it!
Point 8 - Uncertainty. Let other people handle that and hang themselves with it. That's what software architects are for. Be there to clean up the mess afterwards or at least complain about it.
Point 9 - Eventually you do become able to disconnect from your job. One day the fucks just run out. Embrace that early on and save yourself a lot of stress.
Point 10 - The only soft skill is politics. Any sufficiently large organisation employs many politicians. The best way to deal with politicians is analyse the factions and stay neutral. No one can drag you to their side then.
There is a missing point though: objective one is getting paid. Anything else is secondary. If they stopped paying you how much of a shit would you give about all the other concerns? There you go now you understand. Nothing matters so don't get too wrapped up in it or upset about it.
Whenever I see comments like this I feel bad for the commenter.
For all the opportunity and different companies to choose from in tech, to not enjoy your job after 30 years probably means you picked the wrong career path. It’s not healthy to have this much disdain and displeasure around your work.
At no point did I say I don't like this. It's absolutely the best career I could think of. No heavy lifting, no dealing with bodily fluids or excrement, no harsh weather conditions, low to no risk of getting killed, no dangerous chemicals, no being shot at etc. And I get to play with things all the time and solve interesting problems.
I didn't pick up disdain or displeasure from your original message, and I didn't feel bad for you. I felt good for you! I thought "here's someone like me, who's making a decent living in a nice job, but who has a good sense of perspective and isn't getting caught up in the inane irrelevant trivialities of the tech workplace that are ultimately utterly meaningless."
You can make a living doing something you enjoy without having to buy into every single aspect of a corporate workplace and without tangling up your identity with your job. Some of us work to live, and are happy doing that. It's not a failure to be not totally consumed with your career.
Tbf to u/cj, there's a few things you mentioned that would lead one to believe you aren't fulfilled with your job (which, I think, is an important distinction from being 'happy' with one's job).
If 'objective one is to get paid' it comes across as primarily a monetary transaction. That's generally not how the people I know who are really fulfilled in their careers look at it. Sure, pay is an important part, but they also really value aspects like a sense of purpose, the camaraderie of working on a good team, and being able to meaningfully contribute, amongst others.
"One day the fucks will run out." You say this as a point about disconnecting, but you can disconnect while still "having fucks" about your job. Your life doesn't have to revolve around your job, but I don't want to work with a bunch of people who don't really care about what they are doing.
You talk about how you spend remote meetings doing other not-work-related things. I get that meetings can be boring or of little value at times. In those times, ideally, I would prefer someone be honest and say the meeting is of little value and go do something more productive. At the least, I would like them working on something of value to the group while occasionally checking in. You wouldn't act this way in person, so I don't understand why you think it would be ok to do so remotely, other than it's because you can get away with it. Again, that makes it more transactional than contributory.
I could go on with the other points, but all that is to say, I don't think u/cj was completely off with their comment.
I was going to make the same points. Some of these are frustrated and cynical dismissals that may represent reality sometimes, but are counterproductive when taken axiomatically.
For instance, “estimates are lies” fails to acknowledge that planning must still be done in the face of uncertainty, and engineering is the best equipped to do this. The last thing you want is for the pointy hairs to just start pulling deadlines out of thin air. But recognize it’s not about putting in time, it’s about helping the business plan and setting up the team to build things the right way. If you do this well, everyone wins, but it does require the ability to work smoothly with people who don’t share your same expertise and not treat them like idiots.
Planning doesn't mean estimation though; we all know it's just guesswork, and basing business decisions on guesswork is madness. On top of that it's a lot of wasted time and effort.
Milestones and projections is a much more constructive approach, simply tracking the number of tasks in your backlog over time will give you an increasingly correct projection of when the project will be finished.
Very good point, planning is a broader activity than estimation. I find people bring a lot of baggage to the idea of estimation, like in this case you say "it's a lot of wasted time". There's an assumption in there somewhere about what constitutes an estimate. If you're talking about an eng-week granularity estimate for a project that is going to take 6+ months then absolutely I agree with you.
But for me an "estimate" is just a sense of the level of effort required sufficient for the needs of planning at the time. It goes hand in hand with risks, dependencies, and other assumptions that need to be kept in mind. The exact form of an appropriate plan depends a lot on the business constraints like how delivery timeline interacts with customers, external events, and the broader ecosystem that the company operates in.
As for your suggested backlog approach, this makes sense if the requirements are rigid and accuracy on the delivery timeline is the most important thing. This is situational, but in many projects I've led, the scope is negotiable, and therefore important to keep the big picture in mind to find opportunities to refining or consolidating scope. A common anti-pattern I've seen when relying on ticket/task-level tracking is the team missing the forest for the trees. It's possible to leverage these systems to support high-level planning, but I tend to prefer documents or a simple spreadsheet gantt for that purpose, and use ticket/task tracking for last-mile work, intakes, bugs and other inputs that we don't want to lose track of, but may vary widely in their importance and relevance.
To your point, most planning is bad. That doesn't mean planning is worthless when done right. It seems that most bad planning fundamentally misses the interactions between different tasks (ie it largely treats the different tasks as independent). A probabilistic approach that correlates the tasks seems to work better.
Sometimes estimates are made out of ignorance or borne from an optimism bias. But sometimes they are lies, because its easier to get a project funded based on a misrepresentation, and keep it funded once the initial cost is sunk.
The point is they're always guesses, so we multiply by Pi or whatever to make reasonably sure we're not coming up short. But it's all a game, and everyone knows deep down inside that it isn't working.
Maybe it's so prevalent in SWE that most are jaded, but all it means is that we are pretty bad at modeling it or simply don't care. Other domains, like aerospace, have similar problems but have much better methods to arrive at more reasonable estimates (when they care). For example, [1] gets into joint cost/schedule estimating using a more data-driven method where you can put uncertainty around it. It certainly beats 'multiplying by pi.'
Comparing to physical engineering doesn't make much sense to me.
Part of the problem is it's all virtual, so there are no limits; part is that we're always pushing the envelope in the complexity department.
Building the same software again with just a tweak or two doesn't happen very much, the reason we build new systems is often to try something so different that it's not feasible to adapt existing systems.
Most of the time we have no idea exactly what we're building until we get there, even the customers usually have no idea exactly what they want.
Imagine going to a car manufacturer and giving them the kind of specifications we usually get for software, I can assure you they wouldn't be able to give you a good estimate either.
Research is a better comparison. How long will it take you to build a fusion reactor? Depends, right?
There's a lot you've said here that I agree with, but I think we use it to arrive at different conclusions.
FWIW, I've worked in software, automotive, and aerospace. They are probably more alike than you may realize. Vague requirements are quite common. The link above has a section specific to software development, so I don't think it's fair to say it only applies to physical systems. I would characterize it as a systems approach, rather than domain-specific. It uses "WBS" or "work breakdown structure" to delineate tasks. That's an approach that is agnostic to the domain. So if you're working on a mechanical system you might have propulsion, deployment, and control surfaces. If you are working on a software system, it might be user interface, command & control, and data acquisition. But the applicability of the method is the same.
What I think you highlighted is that SWE is generally much less well-managed than other domains. Mechanical engineers often get vague requirements but implement much more standardized processes in their work to hone in those requirements, largely because the costs of jumping in and iterating are much higher. By comparison, software development is the wild west. Like you said, software is virtual, so people are lulled into complacency that they don't need a structured process because they can build and make tweaks cheaply. But what you point out isn't really that software development is inherently different, but just that it's not managed well.
I think your research comparison misses its mark. Research isn't involved with developing some end-stage product for a consumer. The 'product' of research is an experiment and every research project I've been involved with starts with an estimate of how much that experiment will cost and how long it will take. And that follows the same basic structure as any other development effort. Maybe it's an apt comparison for some yet-to-be-proven tech like self-driving cars, but it doesn't explain why most basic CRUD applications miss cost and schedule estimates. I think the answer is that most software development has a culture that isn't as well developed in process control.
And that's my point exactly, every new software system is an experiment. No one has any idea if it's actually going to work out, it's all plug and pray.
If estimating research projects is as much a thing as SW, it's just as insane.
Pretending we know something we don't is lying.
Projections is another thing altogether, let's say we let this run for a month and then we have another look and see where we are. Much more connected to reality than pretending we know where everything is going from square 1.
It’s not any more different than any new mechanical design. Every new car line or rocket design I worked on was an “experiment” just like every new software product. You seem to confuse engineering with mass production. They are two different things.
If you think you’ll get to do research without estimating cost and schedule, you won’t be a researcher for very long. Pretending you know something you don’t is bad project management. But what I’m advocating is estimating with transparency regarding uncertainty. Uncertainty can be quantified. Pretending software is some precious unicorn project that doesn’t have to follow any process is just rationalizing bad process management.
> If 'objective one is to get paid' it comes across as primarily a monetary transaction. That's generally not how the people I know who are really fulfilled in their careers look at it.
Having a fulfilling career is a myth sold to you by employers.
Focus on getting paid enough to have a fulfilling life instead.
After all, chances are the higher ups at your company will fire you at the drop of a hat if they think it will secure them a bigger year-end bonus.
Except it’s not necessarily. As a software developer, you have the privilege to not really care about money if you don’t want to. I didn’t have money problem, ever. Without even trying. I can fly three times between Europe and America, and about 20 more times inside the continent in a year, and I can still put about third of my salary to saving. And I live in a country now where software developers are heavily underpaid: Austria. Most of my friends in other fields can’t even imagine my life - their exact words.
> As a software developer, you have the privilege to not really care about money if you don’t want to.
That sounds nice for you, but your experience is not common I don't think. It's certainly not my experience as a software developer in Canada, where I struggled for years and even now make "just" a comfortable living.
I'm very happy I don't have to worry about rent and groceries and I can save quite a bit, but I'm certainly not able to "not care about money"
HN has a high concentration of above-average salaries, even within the US. It's tough constantly hearing how many multiples more my southern equivalent at FAANG is earning without it affecting my sense of self worth.
I think this is one of the major downsides of focusing on money as the primary part of a job. It can easily become a constant comparison, which has a natural way of making you miserable.
Is it a myth if people have managed to do it? It takes some self-awareness and conscious decision-making, but it's certainly possible.
IMO, a focus on getting paid can lead you to optimize the wrong things in life, making fulfillment less likely than more. It has a weird way of changing your value system by changing what you focus your attention on.
After 30 years in the job, I say that the poster you're responding to is just realistic. I love my job. I love what I do, but it's worth remembering that it's just a job. There is so much more to life.
Not everyone needs to be passionate about the day job. Being present, competent, and reliable is enough. I’d personally go on to say that it’s risky to put too much emotional investment into something you don’t own/control.
I prefer to invest my passion in things outside of my day job. Working is fine, but it’s a means to an end to fuel more meaningful things. We don’t live to work.
"I’d personally go on to say that it’s risky to put too much emotional investment into something you don’t own/control." Bingo! This is exactly what happened to me.
What I learned is that, even in a great environment where there was a ton of latitude to have ownership of technical details and even product details, it's still contained within the broader context of a business. That business has interest in the thing you're working on while it's a factor in creating value, and when it becomes time to change focus onto other things, it will generally do that without much hesitation.
I've been burned by this multiple times. Eventually it clicked for me in the way you phrased it. So I show up and do what I can, bring my expertise as much as I can, gauge where the limits of what I can provide are, and keep a healthy distance mentally otherwise.
One other note - you can still be passionate about software and not one specific day job. You can still work on other projects and explore ideas as much as you want. It's just that that's a separate thing from work. Dedicate time and space separately for that IMO.
> One other note - you can still be passionate about software and not one specific day job. You can still work on other projects and explore ideas as much as you want. It's just that that's a separate thing from work. Dedicate time and space separately for that IMO.
This is what I was trying to get at and you've phrased it beautifully. Thank you.
> There is a world you could be working in a place where you are more passionate and less cynical.
The idea that if you're passionate about something you won't have any complaints about it or enjoy it 100% of the time is unhealthy. Most people realize that there's always an element of 'grind' to any task. You could be the most passionate person in the world, but I can guarantee that something about your passion will annoy you slightly. That's just being human
To some extent presenting a cynical affect is seen as intelligent, or “cool”. The poster claims they like the work, so I’d just take them at their word.
I haven’t found a company yet that meets my energy. All I get is people “excited” to be working for their company because they are “changing” the world. It’s marketing vomit.
To be honest I would prefer to have few million dollars in investments and not to work for anyone at all. No arbitrary deadlines, no corporate ladder, no politics.
I just want to write some code, build some servers and play with things. Maybe make something that benefits people in general.
Most people are faking it. Being able to spend your time on something that both significantly improves humanity and pays the bills is a rare opportunity.
I don't think that's really true (though the claim might be too general to even evaluate on its merits). The same way that I don't believe most religious leaders are secretly atheists.
I've always wondered what substances people are using, the more that they have to touch that stuff. When I was more naive and inexperienced, I was blind to this, and I also judged it.
Nowadays, as long as the marketers are taking care of it, and they aren't ruining their health, I don't care what they're taking as long as it's not meth.
I always wonder this. I think many people actually believe the bullshit because they aren't intellectually curious and have spent no time exploring how other organizations might work. This becomes a problem for software engineering because they have nothing to draw on other than their past work. If they haven't worked anywhere other than your current employer, and your currently employer is a dumpster fire, they are going to continue to repeat bad patterns.
In a company whose business is software-mediated (which is basically all businesses these days), there are a bunch of people who are excited to be part of the journey… and a bunch of tech people who have the power to actually do things because their hands are on the keyboard and they can make the business change.
I know which group I would rather be part of.
Given that being paid to do things is going to involve working for some sort of business, I’d rather be in software development for such a business than in marketing or sales or HR or operational support…
Of course I have. I do make good money but not $500k.
I’m hoping to increase my net worth by few millions in the next 10 years. Getting close to my first one.
I might grind and go for a big tech job, but it needs to be remote.
I then plan on either working an extremely laid back job where I put in 10 hours a week and collect a salary without giving much fucks or doing something exciting that might not pay so much.
Maybe I will find something along the way that excites me.
harsh reality is that 80% of humanity works a dead-end/awful/not wanted job just because bills. IT is a nice bubble in which you do something you are mostly passionate about and you get paid well. I'm not saying "we got it good so don't complain" but sometimes is worth to analyze the situation from the perspectivo of an outsider.
IMO i can do whichever tech job, the more i dislike it the more i need to be paid, that's all
Pretty much any job I might have enjoyed more, if it's not a lot of fancy words for "become a celebrity", will look like minimum wage compared to software engineering. Even when it doesn't, pre-AI software engineers were aggressively stalking around the corners of dark alleys to cut the wages/number of seats of that job.
Most other lines of work guarantee poverty or are a riskier gamble with worse prizes and worse loses.
You want to be at the top of the titanic looking down at those swimming to what's left of the upper deck, not rearranging chairs seconds away from being underwater.
I love writing software and building things that solve real problems, but it’s astonishingly rare to do this as employment. Yet, you still need income as children don’t eat for free. So for the other 90% of us you have to make a choice:
* Go to work knowing you are probably not productively writing software and just accept that reality for what it is: staring out the window while other people listen to the sound of their own voice out loud all day long. And, you often have to drive through lengthy traffic to relish in this experience.
* Write software outside of work at cost to your marriage, time with kids, personal finances, and everything else with work life balance.
They might just have a different perspective than you. I complain about my job a lot. People say to me, “Wow, you must absolutely despise it.” The truth is that if I absolutely despised it I would have left a long time ago. I just have no reason to talk about the good parts. I focus on problems because I want to improve on them.
> I focus on problems because I want to improve on them.
Does this work, though? Does the complaining lead to improvements?
I'm posing the question as a challenge, and also out of curiosity. And I'm of the school of thought that it's necessary to acknowledge reality, but, complaining to the point where people think I despise what I'm complaining about may indicate that another approach may be necessary (such as finding practical solutions and giving yourself options that you can test out).
It’s probably different for every person but complaining about my job either helps me arrive at a solution or realize that I can’t do anything about it and distance myself. I’m very lucky to have never been in a situation yet where the problem is unfixable, truly unbearable, and I also can’t just leave.
Ever hear the term "mid life crisis"? It exists because people around 40-50 - that is 20-30 years into their job they realize they have been doing the same thing and it is getting boring.
While it isn't too late to consider a career change, I'm not sure that is a good idea. For some it is, but many stay - particularly in tech - because they can make a lot of money and thus afford some hobbies that are not boring. Often this is overall your best course in life: find a hobby you enjoy and keep doing your job.
Obviously everyone needs to make their own decisions.
> It’s never too late to consider a career change.
Absolutely, but the huge difficulty is finding a place where the grass is greener. Nearly the whole world is quite equally shitty, it is just the kind of shit that you will see at the various careers ("septic tanks") differs.
I remember going to hackathons and wanting forced timed experience to build anything. I remember going up to the companies that wanted you to build on their stuff and being surprised at their substandard APIs and how lackadaisical and unmotivated those engineering representatives were, I just didnt understand. A fortune 500 team just hanging out a hackathon with no capability or interest in providing real support?
Now I think back and I realize they just had other things to care about
The hackathon and job could be fulfilling, their DIY projects at home were more fulfilling.
Their entrepreneurial endeavors were more fulfilling.
Sure, they could be totally checked out and burned out too.
But it doesnt matter, set boundaries with your job because that definitely doesnt matter.
Aye. Sounds like there are no illusions and a "lets get it done so we get out at 5pm sharp" attitude.
The "I love coding and need to stay to 8pm every day because we're going to change the world!" is insufferable. Hit whatchu gotta hit, don't play the games, and push the release out the door. Then get out there and live life.
Big boomer energy here: it's called work for a reason.
You don't have to enjoy every minute on the job. It's not likely that you're going to be working on passion projects every day. You're not even going to be intellectually stimulated by the vast majority of tasks you will be given. You need to get used to the fact that almost every job as a programmer is probably going to be working on a system that retains eyeballs on screens, counts something, or shuffles around forms.
When you do this for twenty or more years it gets pretty boring. Where are all of the data structures, type systems, formalizations, optimizations, etc? Taken. There are a few people who get lucky enough to have jobs where they can work on things that interest them, where they get to work on hard problems that get them out of bed and plague them while they're in the shower. But they don't leave those jobs and there aren't exactly a ton of new ones being created either. Unless you're lucky enough to be in the right place at the right time to get into one of these jobs, you're more likely to be sitting in meetings and filing JIRA tickets.
Cherish the times when you do get to work on a project that piques your interest. It can happen. But it's rare for it to last for most people. You have to sustain your interest and curiosity in other ways. And it's totally fine if it's anything to do with not-programming.
Meanwhile, on the job? Do your best, show up, be nice and professional. You'll do fine. You're here to clock in your time for money so that you can do other things that you actually like: reading books, spending time with family, doom scrolling, etc.
When I was in college I had a professor who joked that her standards had gone down over the years. Nowadays, her only criteria are: "no criminal record."
Maybe it's just a joke and we don't need to get that cynical, but I think that in the end, enjoyment of the work comes from: whether you can find some creative process in it, and whether you like your coworkers. I think this is the optimistic way of looking at "work is called work for a reason."
To that end, even plain-old programming beats a whole lot of other fields. But to think that we should be drinking the kool-aid and all is definitely not going to stick for the vast majority of us by the second or third decade. I certainly enjoy my job, even though it's just "work."
My professional life and mental health definitely improved when I finally accepted this in full. Whereas at my previous job, the entrepreneurs sold everyone on using the tools and languages of their choice (and sacrificing for compensation in a big way). Noble attempt, perhaps, that may have worked in a different time and era of tech, and under vastly different macroeconomic circumstances. But ultimately, it should not have been surprising, in retrospect, that no one would do any of the work-work that it would've taken to make the company work.
> I think that in the end, enjoyment of the work comes from: whether you can find some creative process in it, and whether you like your coworkers
Hard agree. I look for the interesting things about it and try to, "find the fun." It's nice when you see something you built work well for people, solve problems, etc.
When you get to work on a project that aligns with your values and goals, it's a blessing! Take it, enjoy it, savour it, and write about it. Dive in deep! When it's gone, it's gone.
But there's a lot of busy, necessary work in programming that isn't going to be like that and it still needs doing.
There are a lot of businesses out there that need people to do that busy work and will pay well for someone capable, competent, and willing to do it. It's not glamorous, exciting, satisfying work... it's work. You get paid for it.
It absolutely might be too late for a career change. If you're paid well, and have come to rely on your income, staying put is likely your only realistic option.
Working for any organization comes with its downsides. Pretending like they don't exist and gaslighting someone who's come to peace with them for long-term job satisfaction comes off as pathetic to me.
Spot on! After 16 years, I'm looking to get back to academia and do a PhD. I felt like I don't enjoy what I'm doing for far too long, even though I changed jobs about 8 times.
I used to think like this, but after getting a wife and kids, there’s just no way a corporate job can be continually rewarding like you describe.
Everything is always mired in unpleasant bullshit and emotionally detaching like the above poster suggests is the most pragmatic way to handle work.
I’ve lost all desire of proving myself and working on interesting problems, because at the end of the day, I’d just rather spend time with my family and do fun personal projects. Work is work and it will be never live up to an idealized concept that you have in your head.
> It’s not healthy to have this much disdain and displeasure around your work.
The disdain and displeasure is a result of experience. Of knowing what needs to be done and not being allowed to do it.
> The right way, the wrong way and the Army way
Usually, the problem is the sort of people who get promoted into mismanagement. They were good at "people skills" (and all too often - their only skill is sucking up to their boss) and bad at programming. This is a systemic problem that I have not seen any sort of possible way to fix in all the decades I've been working (or visiting dad's office when a youngster). If you could find a way to ensure that only skilled managers get promoted (and incompetent ones fired), you will fix Capitalism. No more Enrons. No more Innitech.
It's a self-perpetuating process though, since the productive, skilled workers are by definition spending the majority of their time learning and doing productive things, while the remainder have the majority of their time freed up to play political games and elect more of their own political kind into leadership roles. That tends to increase the workload of the productive people, further pushing them away from the nexus of decision-making as they're too busy keeping things running. Eventually a crisis occurs in the top-heavy organization (or society, even). The doers burn out or leave, only demanders remain, and everything goes to shit.
Perhaps worker-owned companies could help with this, but I'm sure that the time investment imbalance dynamic would still be an issue to contend with.
I don't think it is reasonable to expect to truly enjoy one's job. This seems like a luxury that some people in certain fields might enjoy, but most of us tolerate or hate our jobs and wouldn't do these activities by choice.
Your parent post is on-point. You can be passionate about your job and still do the things that he said he does.
You're gunning for absolutism while parent's post is realist.
I love my jobs (yes, all of my employers) but there are few meetings that IDGAF but have to be there because of many reasons. I muted myself and do something else.
I used to be an idealist but I slowly changed my approach because I realized at the end of the day, I'm dealing with human beings day-to-day.
Don't mistake zero-fucks with zero-cares. Staying cool while keeping your sleeves rolled up working on fixes is an absolute life skill. Knowing it's always "Same shit different pile" is maturity, not resignation. Working hard because you are a valuable engineer doing a good job, despite knowing that the world is full of chaos and nothing will matter in 5 years is called Professionalism.
Get paid, invest, be chill and fun to work with, enjoy your family and friends, go fishing or something.
Thanks for sharing your valuable point of view. Unfortunately TV shows, media and being a nerd at home while everyone else was having fun created the myth of the brilliant software engineer that is saving the world through coding - in some cases it was therapeutic or a way to be "different".
Reality is that the software industrialization (which happened after 2000 I believe?) didn't give a damn about those nerds or 10x engineers or whatever: they want decent people that can be replaced as needed. Not necessarily in a cynical way but in a way that every other field works - employees should not become a risk. When that happens, you as a manager have failed miserably.
Yes that's a fair perspective. They wanted fungible staff. The only way to add personal value is to be as non fungible as possible which means being an expert on niche things that the fungible folk aren't. That is usually domain specific concerns and intricacies.
But really I haven't changed the world. I've made it a lot worse. I caused the loss of thousands of jobs. I took money from bastards and con men in return to make things to make the world worse. I celebrated the demise of competitors and their staff going hungry.
And I only did this all because my official qualification didn't pay as much.
That is a choice. Not criticizing you for yours (and bonus points for honesty), but optimizing for money is not the only game in town. Plenty of software engineering work makes the world better while paying enough for a very comfortable life. Not FAANG levels, but good money. My 2c.
This. I've learned that I can't optimize for income, because typically it means I'll be doing work I dislike, or working for a company I dislike. For me, there is no amount of money that can balance that out. I'll prefer a position that pays a bit less but that I enjoy over one that pays excellently every time. To do otherwise ensures I'll have a miserable life.
Others can and do differ, of course. We all optimize for what's important to us.
Yes I agree. I don't make FAANG money but I live comfortably. I think what is important is optimising for a fair balance of happiness in life, which despite my negative outlook here is pretty damn high and taking home enough cash to enable you to do what you want to do before you drop dead.
I'd be more invested in something which improves the human condition but that's a 1 in 100,000 job. Perhaps I should have done biochemistry or something at university.
Hey, if it makes you feel better, a lot of biochemistry research ends up being completely meaningless fluff that is only published to inflate the author's reputation, but will likely have zero effect on the real world.
You can be cynical about anything if you want to :)
>
I'd be more invested in something which improves the human condition but that's a 1 in 100,000 job.
I think the ratio is much larger.
But consider that market forces do work:
Since a lot of people want to do such a job, the salary will be quite low (i.e. so low that there won't be a long queue of people who want to do the job for such a low salary; the salary will just be high enough that the positions can be filled), thus these jobs will typically only be attractive to people really who want to put their money where their mouth is (i.e. their willingness to improve the human condition is so huge that they are willing to accept such low salaries).
On the other hand, the salaries of "bullshit jobs" or jobs where you do evil things will be much larger, because otherwise the company will have difficulties filling the positions.
For what is worth, I appreciate this last bit and I think many others do, too. It's depressing to see a person doing all these things and not seeing through this.
The system is built to capture value (not create it) while externalising as much damage and cost as possible.
The sooner one accepts that the less deluded one needs to be. There's no company 'mission'. The only mission is try to find a way to survive and prosper under hegemonic capitalism.
It's worse than "the system". It's natural human behavior. Take as much as you can for yourself and your friends/family, push the costs onto everyone else. Altruism only happens in proportion to the extent to which it's felt.
Humanity has not yet invented a system that discourages this behavior effectively in the presence of abundance and wealth.
> The only mission is try to find a way to survive and prosper under hegemonic capitalism.
How true this is depends on where the money is coming from. Founders at a bootstrapped company may actually believe in their stated mission. I've seen it. Once investment money gets involved, sure, it's all about the exit. Even the founders may be legitimately confused about this, which results in a lot of mixed messages. Professional leaders who have held executive positions at large enterprises have zero illusions and will probably give it to you straight if you ask them one-on-one.
Sorry I didn't think past listing the horrible things I'd done. Perhaps I should have stuck my business hat on and gone a bit more Cervantes to fit the mould of startup culture?
"One man scorned and covered with scars still strove with his last ounce of courage to reach the unreachable stars; and the world will be better for this."
That's Cervantes? I thought it was by Leigh and Darion. It's possible that they adapted a real (translated) Cervantes quote for a song in Man of La Mancha, but a few Googles don't yield any trustworthy sources that attribute the quote to Cervantes himself.
A "nerd" will be under-utilised and probably dissatisfied in most companies. Most software projects require developers with a level of knowledge that is "industry standard" - being able to write good-enough code in a popular language/stack with a popular IDE and tooling used in a company-specific way. Nobody would care about your vim customisations, the lock-free data structures you implemented, or your deep knowledge of compiler optimisations.
I think this is spot on and that distinction deserves to be in the education of present and future programmers. It's at the root of the different terms (programmer, SWE, computer scientist, developer) and it's not unusual for a role to demand more than one of these types of behavior. But, it's often disheartening to those who would rather spend their time daydreaming in math.
> Reality is that the software industrialization (which happened after 2000 I believe?) didn't give a damn about those nerds or 10x engineers or whatever
That's only true for 95% of companies, not 100% of them. But if you're really in the 5th percentile, you shouldn't care about these 95% anyway. I've been lucky to experience software companies that really care about exceptional engineers (and have proper business incentives to do so), and it truly has been the best place to work at as a software engineer.
> Unfortunately TV shows, media and being a nerd at home while everyone else was having fun created the myth of...
Well, yeah. But how many real careers are accurately portrayed in TV and media, or closely resemble doing $Stuff as a hobby? I'm thinking somewhere between "zero" and "Gell-Mann Amnesia".
Whenever someone refers to planning as “lies” and whines about “politics” … you can be sure they are a difficult person who blames everyone but themself.
The poster is referring to estimation, which is different than planning. Estimating is hard, and requires a many people working together. It can be done for a group, but not for individuals.
In many places estimates are actually lies. There are even plenty of companies where realistic estimates, and well planned projects will get you sidelined. These are often places that reward for fire-fighting rather than planning, and where your value is judged by how busy you appear to be rather than how efficiently you work.
It's important to understand which kind of company you are working in, and if you understand that, then you can adjust your behavior appropriately, and succeed within the environment.
I'm happy to be working in a place that rewards for planning, but I've worked in places where detailed and accurate planning was punished. Oddly enough, this division is surprisingly disconnected from whether the business is successful or not. A good business model will cover a multitude of technical sins.
"politics" just means "large groups of people making decisions together". People love to complain about it, but in reality it is the one tool we have to steer large organizations.
"once God crapped out a 3rd caveman a conspiracy was hatched"
You can't have large groups of people making decisions without politics, and anyone saying otherwise is kidding themselves. You either play the game and pick a side, or someone picks it for you and you get what you get.
Keep in mind this is entirely separate from ruthlessness or backroom deals; this is just the way of things with large groups of people.
I believe it's all about size. Small tasks can be estimated fairly precisely, with 30% margin maybe. But some people extend this logic to huge projects and this simply doesn't work.
I give you example: I was once asked to estimate the amount of work needed to migrate a huge org from on-prem to one of the public clouds. Without even knowing what kinds of app they were running. I said I can only do a very rough estimate and there are too many variables to be precise. But they insisted and hired someone else to do this job with the precision of half-day!
Needless to say, their estimates were too optimistic because they could only include what they knew. By design, they couldn't measure the things they know nothing about because these issues haven't appeared yet. Last time I checked, they are still migrating and I have a feeling they will finish around the time I had originally planned, that is the second quarter of 2024.
When you estimate small tasks, most of the estimates will be accurate, but once in a while, you'll overlook something and a small task turns into a big task, e.g. you need to switch APIs or the customer wanted something that sounded similar but turns out to be much more complicated under the hood. So it's not a Gaussian distribution, it's that once in a while a task blows up.
No, I quickly moved to another team and watched my colleagues get fired or quit one by one as they couldn't keep the estimates done by someone else under pressure. It was a surreal experience.
In my experience, large estimates are only ever Rough Orders Of Magnitude. Our teams do not pull any work in to be done unless they've broken it down to the smallest estimated components. Anything with a large estimate is inherently inaccurate and not ready to plan around.
Acknowledging the ubiquity of politics in organisations is not whining. He only offered a way to deal with it for those not interested in playing the game, or who are not very good at it.
Here is something i encountered, sometimes higher ups will put arbitrarily deadlines and act like the entire business depends on you meeting that deadline for a project and after that deadline passes no one seems to care that much about your product, they even allow you more time to do it "right".
Just to comment on incompetent people. There are kinds of incompetence. It also makes a huge difference where in the hierarchy they are. Incompetent boss will not let you save the day, but will make you take the blame, for example.
Here's an example of incompetence I deal with every day. The head of R&D department either pretends not to understand or is genuinely this stupid as to engage in the following process over and over:
* We release a program with many defects due to the short development and testing cycle, but especially due to poor (or missing) planning.
* Customers complain they cannot achieve what they want using our program.
* R&D lead bravely rushes to "extinguish the fire" by adding new feature to work around the customers' complaint.
* Because the feature was never properly planned it creates multiple new issues while coming late to the testing stage.
* We burn past the deadline, and eventually have to release still half-baked.
* Customers complain again...
There's no place in this scenario where any of the underlings can swoop in and save the day, because saving the day would be to tell the R&D head that he needs to go through due process of planning his contributions and coordinating with other department heads, esp. the QA. But nobody can, because this will be judged as insubordination and violators will be fired. Over half of the underlings are on work visa, not to mention that the company is almost exclusively filling its niche. So, nobody wants to speak up out of fear of being fired.
On the other hand, such incompetence only lowers morale, leading to most underlings losing interest in the subject matter and doing the absolute minimum to hold the job. You'd think it's a miracle such a dysfunctional company keeps sailing... but, I have this to tell you. This is not the first company of this kind I met in my life. All companies of this kind that I've met by the time I've met them were over 20 years old, profitable, big, fearlessly looking into the future...
I love that I work somewhere with no incompetent people (or rarely) as it makes working a lot more fun. You spend most of the day solving real problems.
I had a couple of jobs like that. I looked back and worked out they weren't real problems. They were problems invented to sell solutions for that made money. Supremely productive but alas pointless too.
I eventually developed a philosophy of passive capitalist nihilism. I can't change anything meaningful so I will use the accumulation of capital as a coping mechanism to deal with that.
There are no “real” problems if you have water food and shelter and your family and friends are safe etc. Everything is consumerist driven. Driven by desires.
But my current job they are building something worthwhile and I believe a lot of companies are. But the FAANGs might feel less like that. But let’s say you work for Splunk or Shopify or a government portal or writing drone software or whatever I think it is useful.
I don't think all of this applies in a small outfit. Some of it, sure... Politics is less of an issue in smaller companies. Disconnecting is perhaps actually harder in small companies, idk. Incompetent people can't easily find a place in small companies I reckon, unless, unless everyone is incompetent, in which case the company won't be around for long!
If anything, politics is MORE of an issue in smaller companies, but it usually plays out differently. Be aware of what's going on and _be involved_ or prepare to get blindsided at some point.
Fair points there. Although I have worked for a number of very small companies (startups) that have been successful and totally incompetent, at least one to the order of having the CEO threatened with jail time by the authorities.
Strongly disagree. The smaller the company is, the more political it is. Because now there's no layer to appeal to or to inject sanity; it's the way of the owner or the highway. Being on the right side of the owner is the most important thing and if you're on the right side, you can be as incompetent as you want (see: son of the owner is an idiot, but is the second in command).
Sorry you’ve been burned by nepotism and incompetent leadership. That’s not the root of politics though. Politics is about decision making processes and power dynamics that emerge in large groups. This becomes difficult regardless of competence because power and control become decoupled due the bandwidth limits of single humans, and so the methods of influence and direction become more manipulative and/or more draconian.
depends on the small org. large orgs have a lot of people and a lot of personalities, processes, HR handbooks, you name it.
small companies have a handful of people, and if there is a clash then you're gonna have a bad time. in some ways this is good since you have only to lever or negotiate with 2-3 people, and can get facetime, but if you're on the shit-list it's not gonna happen.
You make a good point. There have been times an HR handbook / department would have been useful. At the end of the day it's a choice I guess, which kind of org you work in. HR departments can also be a bad presence, depending on what is going on for you at the time.
>estimates are always wrong so don't put too much effort into it. What people value is how long you spend making up lies so spend some time on it!
Why people always say this? In my team we have never missed an estimate of what we have planned. I also don't remember it in other projects where team does take time for planning. What is so hard that people find estimating their work?
> What is so hard that people find estimating their work?
Unpredictability for any new work. Even knowing my codebase well, I sometimes forget how changing some piece of code will require changes in other places. And without having done exactly the same work before, I cannot know how difficult it will be and how long it will take.
Dependency on other teammates or other teams. If another team is building something that your work depends on, you have no way of knowing when you'll be finished. If the code you write needs to be reviewed by other team members, and then you'll have to incorporate the suggested changes, this makes it harder for you to say how long something will take.
Maybe you are getting good quality requirements and / or have a system to work on that is somewhat easy to reason about.
Requirements are often hazy. Pushing back on that is good, but if the response is "do it anyway" then you either quit or handle the uncertainty as best you can. The latter makes estimating hard.
If you are going to have to depend on third parties (whether internal or external) that is another thing which can torpedo an estimate that was made in good faith. There would often be too much uncertainty in that situation to be able to accurately account for it in an estimate.
"estimates are always wrong" is obviously an exaggeration - the whole comment is written in that spirit.
> What is so hard that people find estimating their work?
The central difficulty and huge part of many programming projects is actually the "unknown stuff" that is insanely hard to estimate, be it
- requirements set up by users are often very vague
- interacting with some very complicated third-party library/software that takes years to only understand the basics of
- many programming tasks are unique, thus you have never implemented anything remotely related, and thus also have hardly any idea where the difficulties might lie
- the new software "has to behave like the old one". In the old software, there exists an insane amount of corner behaviour where nobody has any idea why it was introduced, but the users will at some point complain if the new software behaves only a little bit different in such an obscure corner case
> The central difficulty and huge part of many programming projects is actually the "unknown stuff" that is insanely hard to estimate, be it
This is my observation as well.
I also think that devs tend to consider the central problem they're solving when estimating, rather than the totality of the work that has to be done in order to complete a task. If I'm tasked with adding a new feature, my mind is focused on the business logic of that feature and if you ask me how long it's going to take, I'll tend to answer the time for just that. I'll tend to forget the time required for all the other ancillary work around that (documentation, UI changes, code review, QA, etc.) Omitting that stuff results in wildly optimistic estimates.
For sure, some teams are way better at estimating than others, and I don't think it helps when a team has the attitude that estimates are some sort of corporate bullshit.
No other engineering discipline has this level of immaturity. Sure, estimates in other industries are also notoriously hard, but you don't see this utter disregard for them you see in software. And, I bet you donuts that every "software engineer" here as demanded estimates from other fields and felt angry when they were missed.
"When is that bridge going to be finished?" "When is the road work going to be completed?" "When is my house renovation going to finish?"
Estimates are important. And yes, they are hard, but there is spectrum of skill levels at doing them well.
Outside of HN commenters, anyway, I don't think I've encountered a dev that doesn't understand the importance of estimates and that thinks they're nothing but BS. Most make honest attempts at accurate estimation.
However, most devs I've worked with were also very aware that estimates themselves have such a large margin of error that they can be considered a bit bullshit even though they are necessary.
Unless the budget is limited, and estimates have to be "optimized" to meet political goals. At that point, disengage and waste as little time as possible on making up shit.
At most companies the stakeholders barely know what they want. They provide a vague idea of what they want, and you give a wild estimate (referred to as a Silly Wild Ass Guess). Knowing all of the details of the problems that one is going to encounter in their old legacy system is basically impossible without spending a bunch of time up front, and you always discover more when you start writing code, so it is best to just start and iterate until you have enough of what the stakeholders want and you move on to the next disaster project.
After 35+ years of software development, you are either lying, incompetent, or worked on exceedingly trivial software. Sorry to be harsh, but I can guarantee you that if you were given a significant software project, asked to estimate and then deliver, that the vast majority of the time your estimates would be wrong.
They could also be greatly padding their estimates. When I estimate things, I take the amount of time I think it will require and double it. In my businesses, my partner would take my padded estimate and quadruple it. By doing that, we never blew past a deadline promised to a customer. That doesn't mean the estimates were accurate -- if they were, no padding would be necessary.
I think it depends on industry, maturity of team (tenure on that project).
I’ve worked on teams that have exactly your experience. I’ve worked on others where they could just never hit the mark. Skills and experiences seemed equivalent. There didn’t seem to be a magic bullet reason, just a whole series of reasonable explanations.
1) The people estimating the work aren't always the ones doing it.
2) Engineers are optimists, estimates are often best case.
3) Not enough padding added to estimates (see #1 and #2.)
It's easy on small teams on small products. Eventually, as capitalism demands eternal growth, they grow to the point that the complexities and hack jobs that were used to deliver previous estimates impact them. Then no one wants to turn up with a realistic estimate. Eventually all the estimates become lies because of the incalculable complexity of the estimation process that results from the complexity of the product and your options are usually to try and lie and deliver late, but not later than other teams in the org.
Every org I've worked for ends up like this.
There is a lot or intellectual dishonesty out there. It used to bother me. It doesn't now. I just don't partake in it.
Learning point 9 early will save you a lot of pain.
I'd add this:
Care about your job, do your best, learn, grow. It'll serve your career and it'll serve your happiness/satisfaction.
HOWEVER, accept that things will go wrong/dumb decisions will be made, and it's not all up to you to fix. If other people make dumb moves, you don't have to die on the hill. Let others fail, it's good for them too. I promise you that nobody will actually care after it's over. It's not worth the mental agony.
>Point 5 - meetings are great if remote. You can sit there muted on a zoom call for hours tweaking with your bike or playing games on your other computer.
What is valued is presence and contributions. That doesn't necessarily require attention for the entire meeting. I'm not going to live forever so I would rather expend that wasted 80% on something that I value. The outcome of the meeting is always the same!
I've asked my coworkers to cancel a biweekly meeting that in my mind creates no value. That meeting still lives on, so I don't feel guilty about reading news or clipping my nails while it happens.
I think they decided to end the conversation there and then when I suggested axing the meeting, so I didn't bother. I just show up every two weeks muted and get noted as an attendee on some pointless meeting document. No skin off my back since I don't own equity.
Not GP, but I once asked my engineering colleagues if I was the only one who doesn't pay attention in the bi-weekly all-hands because most of the information is irrelevant to me (e.g. what new marketing strategies we're using). Some admitted that they would do some work on the side, but some also said "well, those people also want to have a chance to share what they did".
I found this remark puzzling and illuminating at the same time. Apparently, for some people, meetings aren't about productivity but about satisfying psychological needs.
Unlikely. I don't create meetings. I get invited to them. They are mostly unnecessary and have a net negative return of investment. I mean lucky if any of them have an agenda, minutes or an action and rarely does the facilitator actually have any conceptual knowledge of the subject. The meeting exists to service the facilitator's personal value and the naïve process model, not the business, the staff or the customers.
Just stop attending then and do actual work and raise it up with whoever you report to. You are just as guilty for blindly accepting this behavior and then fucking around. Either do your job or do something else.
My retention from any audio is simply better if I’m doing something other than staring at the screen. On meetings that I’ve listened to while taking a walk, I can think back to specific things on my walk and recall exactly what was being discussed, sometimes months or years later. This holds true for doing housework, yardwork etc. There’s some spatial component of memory that wakes up while I do that. It might look like I’m not paying attention to the meeting at all, but I’m actually paying more attention and getting chores done. Win-win.
> Nothing matters so don't get too wrapped up in it or upset about it.
The "it is what it is" way of looking at things, I wish more people in this industry would embrace this.
It more probably won't get one to 600k yearly comps while working at FANGs, but at the same time is a lot more healthy for one's psyche in the medium to long term (and for the psyches of those close to that person, like family and very close friends).
It makes you a target if you position yourself as a faction of one that tries to influence decision making. That's a contest you're not going to win, 99% of the time.
If you just go with the flow, and are reasonably competent, changes in faction dynamics usually wash over you. You end up taking orders from someone else, every now and then, but if blame needs to be pinned on someone, there tend to be juicier targets.
No, if you're competent and have good soft skills, you can survive a purge even if you did not take a side.
I was hired at my previous job by a departing manager who just lost his struggle against our new manager. I managed to finish my job, extend the solution to other teams (as mine went from 12 devs, a handful of Indian support, an Indian QA and PM, to a dev and two level2 support). It was probably my most painful job yet, I regressed, I didn't really 'finish' in the sense that it lacked documentation, good CD pipeline and minor tweaking to make it more efficient, and I hated the last months with my whole being. But politics didn't touch me.
I used to think this too but it rarely works that way in reality. Why? Because, as Roger Sterling put it, "Half the time this business comes down to 'I don't like this guy'".
Incompetent people survive because, for whatever reason, they're liked that decision makers, who may themselves be inccmpetent. Or it may be they're just similar in outlook, background or interests. It doesn't matter. Or they may be politically savvy enough to take credit for things that work and deflect blame when they don't.
I've seen teams spend a half on something, not launch anything, make a post about "we learned a lot" and get praised for thier "achievements".
> Point 5 - meetings are great if remote.
For many people, myself included, this is still incredibly distracting. You can't switch off entirely.
For a software engineer, these are great points to follow if the goal is to be the incompetent person on the team in a few years...
Personally, while I find myself frequently in too many meetings or spending way too much time with email, or $DEITY, git rebasing to satisfy some power-hungry gatekeeper it is the little side projects that save my sanity. While many are the equivalent of throwing paint on a canvas, it is cathartic. So maybe the one good thing to come out of the google mgmt style that everyone seems to have copied (not the side project bit, all the other garbage) is the 20% time.
>
Point 10 - The only soft skill is politics. Any sufficiently large organisation employs many politicians. The best way to deal with politicians is analyse the factions and stay neutral. No one can drag you to their side then.
Staying neutral does not only have the meaning "be diplomatic" or "don't give an opinion", but can also mean "treat all factions equally", which includes the case "treat all of the people who make political attempts with open hate". This way, also no one can drag you to their side. :-)
I think that one very important issue got left out: always be learning. The colleagues that ended up having to change careers were ones who refused to keep current with technology. Or who treated education like a vaccine: "get it" once and never again. "Learning how to learn" is probably the most important skill one learns in college, yet it is treated as a side issue (if at all). So many tech stacks have ended up on the "dustheap of history", yet we have to constantly learn new ones.
Point 9 - Eventually you do become able to disconnect from your job. One day the fucks just run out. Embrace that early on and save yourself a lot of stress.
This is the most important life lesson anyone can learn, but I think it can only be learned by going through a flaming dumpster fire that burns all those fucks away.
You can't get that confidence and no fucks given attitude on your own, at least not for most people. You have to go through the shit and earn it.
Well the people who don't give any fucks want to make their life easier so they do a minimally competent job and are usually supremely skilled avoiding pain. The disconnected people don't actually do any work at all. The incompetents cruise in, full of ego, poop everywhere and expect everyone else to clean it up and take responsibility for it. I don't mind that job because it's an open ended task. As for it being their fault, no it's not really, you're right. But management need butts on seats apparently so standards will be reduced until they are full.
Also many incompetent people, when faced with enough pain, will turn into competent people and eventually stop giving a fuck too.
My college taught me essentials that carry me until this day. Actually, I didn't even know how to use a computer before I got into college, yet I was very well equipped when I graduated. What I was taught was harder and deeper than what I worked on when I started in IBM WebSphere, so getting good at my job, at least to a certain degree, was no big deal. Day-to-day tasks are really not that hard. What's really hard is solving unseen problems, for which the college education becomes really helpful.
>> The college will prepare you for some basics, but what most of the colleges teach is so far away from day-to-day jobs
I depends on what "basics" means. I'd argue that what we need in a job can be easily learned on the job, like a programming language, domain knowledge, CSS this or framework that. What's hard to learn systematically and intuitively (still possible, of course) are fundamentals: matrix calculus for you to understand the basics of deep learning; stochastic process to truly understand diffusion models, OS fundamentals + CPU architecture + parallel programming techniques to truly optimize a complex program, deep understanding of distributed systems to design modern stateful systems, deep understanding of mathematical statistics to come up with new ML models, programming paradiagms so you can learn any programming language easily, end-to-end understanding of how to write a compiler so that you can write a descent compiler or interpreter when you really need to design a DSL instead of thinking YAML + Jinga is the best thing in the world. The list can go on and on, and such fundamentals are really hard to learn systematically on the job.
Case in point, a colleague of mine used to mention how he learned distributed system in his college: his professor would ask them to read a paper before each class, and then the professor would ask them deeper and deeper questions, give them historical context, and challenge them with all kinds of corner cases. How many people could get this level of drilling outside of college?
Another example, in the software engineering classes that I took, we learned a lot of things about formal verification: temporal logics, infinite automata, abstract interpretation, model checkers based on OBDD and on SAT, and etc. So now learning TLA+ for my work is really a delight. I couldn't imagine I would be able to learn all the maths behind formal verification on the job, as I wouldn't have access to professors and TAs for questions, there would be no one to distill a 500-page book into its essences, there would be no seminars for us to discuss papers, there would be no well-designed projects that came with professors' feedbacks, there would be no carefully chosen problem sets that were possible to solve yet thoroughly challenged me...
Its good to share your experience with new comers, I agree with some of it, there's a lot of stuff that's debatable, and I struggle to present my own experience as "truth" to begin with.
> As someone who spent a lot of years in this industry
Amazon calls qualifiers like "a lot" "weasel words", because they hide the information into a subjective expression. I had to go to the authors resume to understand what's "a lot" and it seems that it's 8 years. That's certainly more than average when you consider that the number of devs double every 5y, but I don't consider that "a lot". I have more than double that, and I still don't call that "a lot". I still have massive realization about work every now and then, which prevents me to establish "truths" given that it's all just perception. Side note: I tend to disconnect a little as soon as someone starts a sentence with "as a X", because they're trying to use their qualifiers as proof of what they say.
> College will not prepare you for the job
I feel like my own college prepared me well.
> The majority of software engineers hate meetings. But remember that your job is also to communicate about things openly and proactively.
I hate most meetings because they're useless. Half of the meetings I go to exist because a) someone does not like reading so they want me to read the status I gave in an email b) cargo cult c) because its more convenient for a single person to waste everyone else's. It's great that we can have meetings, some are productive, but in a software company that ships software, protecting the time of people who actually write the software seems like a good idea.
> Nobody gives a f** about your clean code
In the companies you went to, maybe. I give a f** about clean code, because once in a while I am gonna get called at night because stuff's broken, and I don't want that to be because of your shitty code. (also, I rarely saw a college graduate produce clean code, it seems to be something that you need to have experience to do).
> You will profit more from good soft skills than from good technical skills
There's truth in there, it's important to develop your communication and presentation skills. To be fair a lot of my graduate year at college was around that so, once again, I felt prepared. Saying that you will benefit more from that than tech skills is against a stretch that will vary based on where you are at on both sides, and generally speaking it pays more to be good at what you are being paid for.
> It will be almost impossible to disconnect from your job
Strong disagree, and I don't think that this is a message you should transmit. Funnily I think I pivoted my point of view on that topic around the experience level of the author. I think it's a tendency of your early years, when career is your priority, to always prioritize career. Later, when you find other things you enjoy, disconnection from work is entirely possible. Don't take your computer when you leave for vacation. Be strict about not communicating after hours. Dont reply to your phone (I don't even have work emails on my phone). If you really love your job and spending more time in it is your hobby, go for it. If that's not the case, learn to disconnect.
> As in every job, you will sometimes have incompetent people in your environment. Working with them is very frustrating. They waste so much time and create a toxic environment. On top of that, they are extremely unproductive.
That is not even the worst case. There are incompetent people out there that look like they are productive.
An example: once we had to implement a bridge to an API to some piece of software from some third party vendor that one of our customers used. This started with authentication. Of course they didn't use OAuth or anything like it but their homegrown bastardised version: you authenticate with a username + password - nope, not a refresh token - and it hands you a temporary token that you then use to hit the API until it expires.
Of course it didn't hand you expiration time so you'd have to do requests until they failed, at which point you did the login dance to get a new temporary token.
Of course it didn't fail with a 403 or any other status code or in-band information you could use: everything failed with a 500 and an empty body. But that's not even the worst part.
Of course there was no HTTPS, so everything went in clear over the interwebs. Not to fret, they thought of that: they implemented encryption. Oh, before you ask no they did not use a Authentication header or anything remotely like it, for the login phase they had us pass username+password on a GET request query string, with values encrypted.
Of course they did not use anything cryptographically reasonable that you could find off the shelf, instead choosing to shoot themselves in the foot with using the OpenSSL API to come up with their own thing. So they picked the worst possible thing ever, ECB - If you have no idea how bad ECB is, click the following link and let it sink for a moment that you're looking at the ciphertext.
Of course they provided documentation with three code examples (C#, Java, PHP) so as to implement it. Of course each one of these four had gaps covered by the others, yet the overlaps had none of these four things agreeing.
Of course the code for the statically typed languages did not even pass the compiler.
Of course the code examples were ostensibly copy pasted from StackOverflow, and then further butchered (with localised names).
Of course the actual server implementation was a fifth thing that disagreed with the four above. So the easiest way was to "simply" MITM their official Flash client and brute-force-reverse-engineer the payloads, tuning OpenSSL arguments until your code produced the same output as what you intercepted. In a twist of irony, this being ECB helped.
And no they did not use anything like public+private keys, DH, or even a PSK, however fancily implemented. See, values were encrypted for every payload, but how do you make the API server understand your first request ever: the login? Of course you would not send the username and password in the clear over the web! So it has to be encrypted! So you encrypt it and stuff it as a value in the query string! But now how does the server which has no idea what the key is can decrypt it? Easy! Base64 the key and pass it as a second query parameter! Now auth is encrypted and the server can decrypt it! To hell with "PS" in "PSK", that's for losers!
Of course, somewhere, someone got accolades for having implemented that API in record time complete with full documentation and examples, ready for folks like us to peruse.
Of course we had to vigorously defend ourselves for being comparatively unproductive in front of two CEOs (including ours), a CTO, a contractor, and an employee that implementing a client to this API is taking us more than an afternoon, and that, glossing over the details about the fitness of ECB, it was a stupendously pointless loss of everyone's time when the API vendor required us to pass the key in cleartext alongside the encrypted payload, a fact that probably still eludes all of them to this day.
Really good reframing and perspective. I think all this absolutely can be spot on. I have personally experienced this kind of work a few times in my career, and yeah, I agree that when I'm in one of these environments, it's almost certainly a better job than anything else anyone else I know is doing.
But I also think the ability to flip the script into this positive experience really does vary between organizations and even within organizations. And it's basically impossible to evaluate it accurately before taking the job and doing the first three to six months of work there. And then if you do conclude it's not a conducive environment to do great work in, it's easy to feel stuck, or to very reasonably feel like you might just go through the exact same thing at the next organization after putting a bunch of energy into getting unstuck.
I don't really have advice here I guess... I think there's a lot of luck involved.
I guess maybe my advice would be that I think this is one of the good reasons to start out at a "big tech" company if you can. They have all these difference that exist across companies, but they have them across teams or divisions within a single company, and it's both a bit easier to figure out what the good teams are, and a bit easier to switch teams than companies.
I think software development “is not a dream job” as people outside think it is.
Most of the time people think you get paid for sitting behind the screen. Which is also true and might be hard for some types of people on its own.
But a lot of people don’t want to be measured on results, don’t want to deal with learning new stuff on the job, having responsibility for something complex that might break at any time quite often for reasons totally not in their control.
I like my software dev job and I also would not switch but I can see how it is not a dream job.
> don’t want to deal with learning new stuff on the job
I think this might be the big one. A few years ago I got small window into someone going from no programming experience to getting a job (completely self-directed, not through school or a bootcamp) and he thought he had to learn everything before getting the job. I had to reassure him that no, that's really not how it works in tech - even if you could learn all of ___ right now, there's stuff continually being added so you'll have to keep learning anyway. Basically that typically you'd get the basics down then learn new stuff as you needed it.
His previous experience mostly came from a mix of skilled and unskilled laborer jobs, where even the skilled laborer ones you could learn everything in like 6 months and from there onwards it's just refining skill (as he described it, at least).
> But a lot of people don’t want to be measured on results, don’t want to deal with learning new stuff on the job, having responsibility for something complex that might break at any time quite often for reasons totally not in their control.
See the blog's paragraph on incompetent colleagues. :D :D
I'm with you but it depends on the company - I was responsible to keep it running for the customers and my boss thought it's better to let me churn out useless work that he can bill instead of fixing the issues or simplify the process (at least internally). I even proposed that he can just bill the same or more hours for the customers for me but I need to automate that shit or I'll go insane. Didn't happen. As soon as I realized that I quit but I burned out pretty badly trying to make it work because I liked the team and the product. Be careful and watch out where you spend your energy and time.
You're having a blast because you have a great attitude towards your work and feel empowered. This isn't always true for everyone, particularly if you're in a situation where the organization around you isn't healthy.
I love software engineering too but being a "key contributor" golden handcuffed to an organization that's "optimizing costs" has made me appreciate why some people might not enjoy this line of work.
The thing about ‘jobs’ is they pretty much all involve working for companies.
So ‘dream jobs’ and ‘nightmare jobs’ alike are going to share all the downsides of that: clueless management, misaligned incentives, layoffs, etc.
But my point is, if you’re going to have to work for a company anyway, software engineering isn’t a bad profession to choose.
Additionally, if you decide you would rather work for yourself than put up with corporate life there are few jobs that pivot as easily into starting your own business or becoming a consultant.
You're just furthering my point that your good attitude is a major component of your success. I agree with you 100% and I'm always grateful I get to work in this career, bad parts and all.
For the record, you sound like exactly the kind of person I like working on my teams.
Might be an age thing.
This is a positive spin, and I agree.
But the stress does eat away at health. It can be fun, but it is not 'comfortable'.
Maybe it is different if you are writing some mission critical code. It can be fun when you are dabbling with web sites, but not so fun if a bug will cause someone to die. So stress levels, and having a blast levels, can very a lot.
And thus the stress levels over time, can cause health problems.
Like, young enough to still be enjoying things. Sure, I felt the same way for first decade. This is all fun.
But later.
Not old enough yet to have done 24x7 support for a few decades, sleepless nights, 80 hour weeks, working on Christmas Morning, to be ground down by angry and demanding users. ( no fault of their own because of their own turnover. ).
Lack of sleep and stress takes a toll on health. So 'age' becomes a factor, because the body gets ground down. Seems like the 'optimistic' takes remind me of just starting out.
But, it is probably more of which industry you are in. Results vary.
eg video games sound like such fun to work on, but every report I've heard of from people who actually work in that industry make me run away screaming that I've never had a programming job in that sector.
Well said. I think misanthropy and pessimism are endemic with people who spend 14 hours a day talking to computers and don't have healthy social lives or many reasons to touch grass.
You will primarily work with (and for) other human beings, inside your organization and outside.
The measure of your success is often perceptive, coming from a boss, a coworker, or a client, and it may not directly correlate with your perception of what you may or may not have personally invested into the solution.
Software engineering is philosophically no different than plumbing -- sometimes the job is designing and implementing a plumbing system in a new building, other times it's diagnosing the source of a leak and fixing it, many times it's clearing literal feces from a pipe. Your value is not just extracting those turds, it's often being calm, competent, compassionate, timely and communicative while doing so. It comes from perseverance for solving the problem to the customer's satisfaction. It also comes from defusing situations with angry / incompetent clients, disaster projects, and resolving chaotic situations. Your role is to help reduce friction and solve problems for a person or organization in need.
That you're writing software is purely coincidental; it's but one of many deliverables you provide throughout the course of your career. The rest are "soft" -- insight, support, quality, reliability, trust, consistency, charisma, general likeability as a human being, etc.
If you're doing this for a job, you're going to have to deal with a lot of people, a lot of arbitrary constraints, a lot of bullshit, and a lot of bureaucracy that have nothing to do with writing software.
The same argument could be made for law, medicine, engineering, hospitality, cooking, fashion design, driving a taxi, street performing, drug dealing, sex work, you name it.
That's just the reality of work! If you're more interested in making art, do that instead (or both at the same time), but try to understand that there's a marked difference, and they serve separate, necessary roles in life :)