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.
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.
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.
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].
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 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.
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.
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.)
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.
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".
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.
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?"
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.
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.
> 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 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.
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?
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!
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.
> 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.
> 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.
> 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?
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!"
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.
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).
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.
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.
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.
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.
General practice and primary care are all about what's common. It's designed to soak up all the easy stuff that makes up 80% of the cases so that the specialists can deal with the hard complicated 20% stuff. If a doctor can't help you, they should still know who to refer you to.
Can you give an example of a slightly unusual symptom that stumps doctors?
Yes- I've had the same experience... the same "Huh, that's weird" kind of unknowing response that I give my parents when their printer isn't working again
Both of those experiences exist, though - if you want to build applications from scratch, go join a really early stage startup. It's strange to me that people are surprised that when you're one of hundreds or thousands of software developers in an organization that you don't get to work on freewheeling projects based on what you want to do.
Also, I don't think there's a platonic ideal of a software developer - there's a lot of mid-40s devs who have children and whose platonic ideal is a well-paying job with good work-life balance.
>Do other careers have such a vast gap between the platonic ideal and the actual lived experience?
I'm not paid boatloads of money for 99% of my work, i'm paid boatloads of money for the 1% of the time I have to do something very impactful. If using the right data structure for your 'cancel prime membership button' means a .1% server load reduction and 1% higher reliability, it's worth paying Joe Blow Amazon SDE 300k a year.
It's the same with Doctors. Most of the time they say "take two Tylenol and call me in the morning". Or maybe they're stitching someone up in the ER and they're doing just as good of a job as a nurse. But once and a while they save lives with their decision making.
Yes. Pretty much all of them. Most jobs are more about the realistic situation on the ground. Very little of which is "platonic ideal"? Even if or when you get to have a whole team of assistants to do the menial stuff you don't consider part of your "platonic ideal", you'll find yourself in the management and coordination business. A good manager will shield you from some of this but most of the job IS this. People tend to talk about the fun stuff but the good news is, you are reading HN so you also hear plenty about the not fun stuff.
> Do other careers have such a vast gap between the platonic ideal and the actual lived experience?
I used to really enjoy this blog from this american medical student. This guy seriously hated medical school and the worst part is I don't even blame him.
> The way most people talk about software engineering, you'd think they were some kind of open-source warrior building entire applications from scratch when really they're on the Cancel Prime Membership Button Obfuscation Enablement team at Amazon.
True, if one apply most of the lessons in the article (e.g. "Nobody gives a f** about your clean code") to a well-established open source project, the maintainers will grind you to death.
+ Compensation is insane. I don't think there is anything else in the world I am qualified to do that would pay me nearly as much.
- Deceptively long hours
- Constant deadlines that are often solely dependent on you. If you are at the senior level or higher, there are often features that depend only on you. If you miss a deadline, several people up the chain will most likely know about it. There is no one to share the "shame" with. It's all on you.
+ Flexible schedule. Every place I've worked has been very accommodating (usually to the point of not caring at all) of family obligations, doc appointments, start time, etc.
- Constant objective changes. Speaking from FAANG, things are constantly changing. You could be months into a feature, priorities shift, and they shelf the whole thing. Not to mention the re-orgs.
Overall, I feel very fortunate to have this career. I often see folks my age grinding away at some soul sucking job and my gratitude intensifies. However, it's not all sunshine and rainbows. The nap pods and ping pong tables are just a recruiting tool, not part of day to day life.
I'm just saying, compare what you're making to the average person your age. Take into account the amount of debt that comes along with some of the professions requiring extensive schooling. Also consider the conditions and work life balance (ex: welders can make a great deal of money however they are often away from home for months and work 6-7 days a week in rough conditions).
Even if you're not at FAANG, overall, we're making a lot of money working from a comfy chair with little to no required debt.
Comp's not insane in the rest of the industry, but is just about the only non-management route to the 1960s-1990s style middle class that remains. It's a lot of money compared to median income.
Even outside of FAANG the pay is still quite generous, at least from my experience in.... US/AU/UK/etc
You get paid so much for relatively so little. Housemate was a chef who's work was so much more demanding physically and worked stupid hours, and was paid a fraction compared to developers.
I have never encountered a profession that complains as much about their job as Software Engineers. I've worked many jobs in my life: restaurants, construction, teaching, IT Support and so far the best one has been software development. Every job has its annoying BS. I get it's not for everybody, but at least I get to solve puzzles all day instead of digging post holes or dealing with shitty customers.
I wonder where you live for that to be true, in my experience everyone just complains all the time about the previous guys' craftsmanship and that's especially true in trade and engineering.
> restaurants
KitchenConfidential is a subreddit dedicated to complaining about shitty customers.
> construction
If you don't hang out with construction worker, you can find almost any YouTube video that goes over some aspect of homebuilding, scroll down and see comments with "As a carpenter of 15 years that guy is a moron for X and Y".
> teaching
I don't have public examples of that one but a lot of my friends are teacher and they are an absolute blast to be around because they keep complaining about stupid helicopter parents, overbearing principals and other bad encounters. No idea what kind of teacher you hang out with. Same goes for doctor and nurses btw, put two of them together in a room and they will start complaining about patient X and Y.
> IT Support
There are 4-5 subreddits like TalesFromTechSupport that are literally only stories from IT technicians.
All of the above to say, really happy for you if Software Engineers are the ones that complain the most.
One unique aspect of software engineering is that it is still growing exponentially, doubling approximately every five years.
As a direct consequence of the mathematics of exponential growth, this means that:
HALF of all software developers have LESS THAN 5 YEARS of experience!
This results in experienced devs being simply outnumbered by newcomers and having to perpetually fight against the rising tide of beginner errors.
As someone with nearly four decades of experience, I'm facing six such doublings (plus retirees subtracting from the experienced pool!), meaning that I'm outnumbered by people will less experience 64-to-1.
In my time I've seen every wheel reinvented -- badly -- at least three or four times over. I've seen the same huge, glaring mistakes made over and over by new people. It's literally impossible to convince them of their mistakes because it's one voice against dozens.
Few if any other industries are like this because they don't have the same insane growth curve. Surgeons with less than 5 years of experience are hugely outnumbered by surgeons with 10, 15, 20, etc... years of experience all the way up to 50+. They don't get to overrule the Chief of Surgery. They're told to shut up and learn how to do things properly by people who made mistakes and learned from the consequences.
As a random example of this effect, the entire industry is learning for like the third or fourth time that text-based formats are not better, and their "ease of use" is a deceptive trap.
JSON is just text, and is "so easy" -> gRPC, a binary wire format.
HTTP is just text, and is "so easy" -> HTTP/3, a binary protocol.
This kind of thing will keep happening until the exponential growth transitions into the flat bit of the S curve, and the average experience level starts climbing towards two decades.
Pete Davidson joked that depression is a rich person's condition because it implies you have a life you shouldn't be depressed about. Same with software engineers?
I know mental health issues and suicide attempts correlate much more strongly with folks lower on the socioeconomic ladder, but when I was poor I was too busy to be depressed in the same way I am today. Now my life is far easier, yet also somehow much more depressing.
Almost every teacher I've known has complained a lot more than most of the S/W engineer folks I know. I do complain a bit myself though, but I think that's a reflection of having high standards and an eagerness to improve things (to put a positive spin on it).
You do make a good point though - we don't have to work in the sleet, or in human filth in a 2 foot crawlspace filled with spiders. It could be a lot worse!
I complain because the impact I can have on people's lives now is far greater than when I was working fast food or picking orders in a warehouse, but the people I work with either don't give a shit or are incompetent. Then we wonder why dealing with various companies is so irritating and they create so many problems in our lives.
Readit News
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 :)
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.
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)
> 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.
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.
Deleted Comment
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.
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.
"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.
It's about where you are at relative to the median in the group, typically, not about any absolute standard.
New business or acceptance criteria, architectural changes, and other human created obstacles.
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.
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")
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.
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.
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].
1 - https://www.wsj.com/articles/BL-LB-4558
Don't you know a bad API, variable name, or architecture when you see one?
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.
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.
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.
[0] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
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.
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.
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.
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.)
> 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 don't think how you can avoid that unless you find people that have similar ideas to you about how to write code.
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.
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)
Deleted Comment
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?
Name five good things that Hillary has done.
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".
You got me absolutely confused here. There are 5 good things she had done? I think this proves that a bad alternative can get anybody elected.
> 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.
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.
Estimating things you've never done is hard.
Estimating things you've done a lot is trivial, and pointless.
When people saying that estimating is hard, they don't mean they easy kind.
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.
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?"
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.
Uhhhhhhhhhhh....
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.
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.
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.
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)
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.
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?
Corollary 4: Never buy version 1 of anything.
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.
don't blame the player, blame the game.
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.
Of course the only way to obtain a precise measurement is to start the clock and do the thing.
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.
They seem to have a lot of spare time and work on toy projects often.
I do wonder whether this was escalated, to either the previous team lead, some other manager, or just a shouting match in the corridor.
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.
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?
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.
Deleted Comment
Surprisingly, it didn't work.
And he could find the same amount of deficiencies in your own code. You can always find something if you search hard enough.
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 :)
Matt Levine wrote another epic LOLfest about a similar topic yesterday. [0][1]
I recommend subscribing to his column as the email is always full length piece without the paywall.
[0] https://www.bloomberg.com/opinion/articles/2023-11-07/bridge...
[1] https://archive.ph/CQUn9
Edit: seems to be an issue with DNS over HTTPS, change provider from cloudflare to nextdns solved it (per https://www.reddit.com/r/AskTechnology/comments/162w00q/gett...)
This is some bullshit that losers subscribe to.
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.
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!"
They never do though. People's reward for "improving the business" by being efficient is more work, not more money.
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?
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.
Deleted Comment
https://tinyhydra.com/the-scotty-principle/#what-is-the-scot...
Deleted Comment
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.
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 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.
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).
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
* 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.
Yeah having kids fixed that for me
Clearly that's not the case for everybody. Don't assume that your reality - and what works for you - is universal truth.
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).
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.
Only way to find peace with this mindset is to go all-in on your own dream(s) not your boss' dream. May require a leap of faith...
Isn't that a truism? If you only work, there is not much time for anything else, I think.
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.
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.
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.
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.
The site nearly every MD in the US uses is called UpToDate:
https://www.uptodate.com/login
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.
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.
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.
Can you give an example of a slightly unusual symptom that stumps doctors?
of treating the most comments stuff and being lost? Would have thought the opposite, no, or am I misunderstanding
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.
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.
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.
https://web.archive.org/web/20101218031844/http://www.medsch...
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.
Any NGO worker or nonprofit probably has this. Nurses, doctors, and veterinarians also.
Here's my pros and cons:
+ Compensation is insane. I don't think there is anything else in the world I am qualified to do that would pay me nearly as much.
- Deceptively long hours
- Constant deadlines that are often solely dependent on you. If you are at the senior level or higher, there are often features that depend only on you. If you miss a deadline, several people up the chain will most likely know about it. There is no one to share the "shame" with. It's all on you.
+ Flexible schedule. Every place I've worked has been very accommodating (usually to the point of not caring at all) of family obligations, doc appointments, start time, etc.
- Constant objective changes. Speaking from FAANG, things are constantly changing. You could be months into a feature, priorities shift, and they shelf the whole thing. Not to mention the re-orgs.
Overall, I feel very fortunate to have this career. I often see folks my age grinding away at some soul sucking job and my gratitude intensifies. However, it's not all sunshine and rainbows. The nap pods and ping pong tables are just a recruiting tool, not part of day to day life.
What?
> Speaking from FAANG
Oh.
Even if you're not at FAANG, overall, we're making a lot of money working from a comfy chair with little to no required debt.
You get paid so much for relatively so little. Housemate was a chef who's work was so much more demanding physically and worked stupid hours, and was paid a fraction compared to developers.
> restaurants
KitchenConfidential is a subreddit dedicated to complaining about shitty customers.
> construction
If you don't hang out with construction worker, you can find almost any YouTube video that goes over some aspect of homebuilding, scroll down and see comments with "As a carpenter of 15 years that guy is a moron for X and Y".
> teaching
I don't have public examples of that one but a lot of my friends are teacher and they are an absolute blast to be around because they keep complaining about stupid helicopter parents, overbearing principals and other bad encounters. No idea what kind of teacher you hang out with. Same goes for doctor and nurses btw, put two of them together in a room and they will start complaining about patient X and Y.
> IT Support
There are 4-5 subreddits like TalesFromTechSupport that are literally only stories from IT technicians.
All of the above to say, really happy for you if Software Engineers are the ones that complain the most.
However, creating a blog for your complaints seems unique to software developers, lol.
As a direct consequence of the mathematics of exponential growth, this means that:
HALF of all software developers have LESS THAN 5 YEARS of experience!
This results in experienced devs being simply outnumbered by newcomers and having to perpetually fight against the rising tide of beginner errors.
As someone with nearly four decades of experience, I'm facing six such doublings (plus retirees subtracting from the experienced pool!), meaning that I'm outnumbered by people will less experience 64-to-1.
In my time I've seen every wheel reinvented -- badly -- at least three or four times over. I've seen the same huge, glaring mistakes made over and over by new people. It's literally impossible to convince them of their mistakes because it's one voice against dozens.
Few if any other industries are like this because they don't have the same insane growth curve. Surgeons with less than 5 years of experience are hugely outnumbered by surgeons with 10, 15, 20, etc... years of experience all the way up to 50+. They don't get to overrule the Chief of Surgery. They're told to shut up and learn how to do things properly by people who made mistakes and learned from the consequences.
As a random example of this effect, the entire industry is learning for like the third or fourth time that text-based formats are not better, and their "ease of use" is a deceptive trap.
JSON is just text, and is "so easy" -> gRPC, a binary wire format.
HTTP is just text, and is "so easy" -> HTTP/3, a binary protocol.
This kind of thing will keep happening until the exponential growth transitions into the flat bit of the S curve, and the average experience level starts climbing towards two decades.
You do make a good point though - we don't have to work in the sleet, or in human filth in a 2 foot crawlspace filled with spiders. It could be a lot worse!
Deleted Comment
Deleted Comment
Deleted Comment