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.
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 :)