Whenever I see comments like this I feel bad for the commenter.
For all the opportunity and different companies to choose from in tech, to not enjoy your job after 30 years probably means you picked the wrong career path. It’s not healthy to have this much disdain and displeasure around your work.
It’s never too late to consider a career change.
At no point did I say I don't like this. It's absolutely the best career I could think of. No heavy lifting, no dealing with bodily fluids or excrement, no harsh weather conditions, low to no risk of getting killed, no dangerous chemicals, no being shot at etc. And I get to play with things all the time and solve interesting problems.
But it is what it is!
Right, but you are cynical and dispassionate. There is a world you could be working in a place where you are more passionate and less cynical.
(This could be more personality than experience though, so I agree it could be a misread)
After 30 years in the job, I say that the poster you're responding to is just realistic. I love my job. I love what I do, but it's worth remembering that it's just a job. There is so much more to life.
Amen to that. Work to live, don't live to work.
Not everyone needs to be passionate about the day job. Being present, competent, and reliable is enough. I’d personally go on to say that it’s risky to put too much emotional investment into something you don’t own/control.
I prefer to invest my passion in things outside of my day job. Working is fine, but it’s a means to an end to fuel more meaningful things. We don’t live to work.
"I’d personally go on to say that it’s risky to put too much emotional investment into something you don’t own/control." Bingo! This is exactly what happened to me.
What I learned is that, even in a great environment where there was a ton of latitude to have ownership of technical details and even product details, it's still contained within the broader context of a business. That business has interest in the thing you're working on while it's a factor in creating value, and when it becomes time to change focus onto other things, it will generally do that without much hesitation.
I've been burned by this multiple times. Eventually it clicked for me in the way you phrased it. So I show up and do what I can, bring my expertise as much as I can, gauge where the limits of what I can provide are, and keep a healthy distance mentally otherwise.
One other note - you can still be passionate about software and not one specific day job. You can still work on other projects and explore ideas as much as you want. It's just that that's a separate thing from work. Dedicate time and space separately for that IMO.
To say it's "personality" is a little passive aggressively degrading. These opportunities are not accessible or sensible to everyone all the time.
I think you misread my intent. I was saying it could be personality of cynicism (which is fine) and nothing to do with the job.
There is a world you could be working in a place where you are more passionate and less cynical.
The idea that if you're passionate about something you won't have any complaints about it or enjoy it 100% of the time is unhealthy. Most people realize that there's always an element of 'grind' to any task. You could be the most passionate person in the world, but I can guarantee that something about your passion will annoy you slightly. That's just being human
I don’t disagree. Sorry I feel people have misread a lot more malice into my comment than I intended.
I felt sympathy for the OP not superiority.
I am passionate about the things I'm interested in, not all the unnecessary fluff around them :)
Tbf to u/cj, there's a few things you mentioned that would lead one to believe you aren't fulfilled with your job (which, I think, is an important distinction from being 'happy' with one's job).
If 'objective one is to get paid' it comes across as primarily a monetary transaction. That's generally not how the people I know who are really fulfilled in their careers look at it. Sure, pay is an important part, but they also really value aspects like a sense of purpose, the camaraderie of working on a good team, and being able to meaningfully contribute, amongst others.
"One day the fucks will run out." You say this as a point about disconnecting, but you can disconnect while still "having fucks" about your job. Your life doesn't have to revolve around your job, but I don't want to work with a bunch of people who don't really care about what they are doing.
You talk about how you spend remote meetings doing other not-work-related things. I get that meetings can be boring or of little value at times. In those times, ideally, I would prefer someone be honest and say the meeting is of little value and go do something more productive. At the least, I would like them working on something of value to the group while occasionally checking in. You wouldn't act this way in person, so I don't understand why you think it would be ok to do so remotely, other than it's because you can get away with it. Again, that makes it more transactional than contributory.
I could go on with the other points, but all that is to say, I don't think u/cj was completely off with their comment.
If 'objective one is to get paid' it comes across as primarily a monetary transaction. That's generally not how the people I know who are really fulfilled in their careers look at it.
Having a fulfilling career is a myth sold to you by employers.
Focus on getting paid enough to have a fulfilling life instead.
After all, chances are the higher ups at your company will fire you at the drop of a hat if they think it will secure them a bigger year-end bonus.
Except it’s not necessarily. As a software developer, you have the privilege to not really care about money if you don’t want to. I didn’t have money problem, ever. Without even trying. I can fly three times between Europe and America, and about 20 more times inside the continent in a year, and I can still put about third of my salary to saving. And I live in a country now where software developers are heavily underpaid: Austria. Most of my friends in other fields can’t even imagine my life - their exact words.
As a software developer, you have the privilege to not really care about money if you don’t want to.
That sounds nice for you, but your experience is not common I don't think. It's certainly not my experience as a software developer in Canada, where I struggled for years and even now make "just" a comfortable living.
I'm very happy I don't have to worry about rent and groceries and I can save quite a bit, but I'm certainly not able to "not care about money"
Is it a myth if people have managed to do it?
Focus on getting paid can lead you to optimize the wrong things in life, making fulfillment less likely than more.
I was going to make the same points. Some of these are frustrated and cynical dismissals that may represent reality sometimes, but are counterproductive when taken axiomatically.
For instance, “estimates are lies” fails to acknowledge that planning must still be done in the face of uncertainty, and engineering is the best equipped to do this. The last thing you want is for the pointy hairs to just start pulling deadlines out of thin air. But recognize it’s not about putting in time, it’s about helping the business plan and setting up the team to build things the right way. If you do this well, everyone wins, but it does require the ability to work smoothly with people who don’t share your same expertise and not treat them like idiots.
Planning doesn't mean estimation though; we all know it's just guesswork, and basing business decisions on guesswork is madness. On top of that it's a lot of wasted time and effort.
Milestones and projections is a much more constructive approach, simply tracking the number of tasks in your backlog over time will give you an increasingly correct projection of when the project will be finished.
Very good point, planning is a broader activity than estimation. I find people bring a lot of baggage to the idea of estimation, like in this case you say "it's a lot of wasted time". There's an assumption in there somewhere about what constitutes an estimate. If you're talking about an eng-week granularity estimate for a project that is going to take 6+ months then absolutely I agree with you.
But for me an "estimate" is just a sense of the level of effort required sufficient for the needs of planning at the time. It goes hand in hand with risks, dependencies, and other assumptions that need to be kept in mind. The exact form of an appropriate plan depends a lot on the business constraints like how delivery timeline interacts with customers, external events, and the broader ecosystem that the company operates in.
As for your suggested backlog approach, this makes sense if the requirements are rigid and accuracy on the delivery timeline is the most important thing. This is situational, but in many projects I've led, the scope is negotiable, and therefore important to keep the big picture in mind to find opportunities to refining or consolidating scope. A common anti-pattern I've seen when relying on ticket/task-level tracking is the team missing the forest for the trees. It's possible to leverage these systems to support high-level planning, but I tend to prefer documents or a simple spreadsheet gantt for that purpose, and use ticket/task tracking for last-mile work, intakes, bugs and other inputs that we don't want to lose track of, but may vary widely in their importance and relevance.
I didn't pick up disdain or displeasure from your original message, and I didn't feel bad for you. I felt good for you! I thought "here's someone like me, who's making a decent living in a nice job, but who has a good sense of perspective and isn't getting caught up in the inane irrelevant trivialities of the tech workplace that are ultimately utterly meaningless." You can make a living doing something you enjoy without having to buy into every single aspect of a corporate workplace and without tangling up your identity with your job. Some of us work to live, and are happy doing that. It's not a failure to be not totally consumed with your career.
I love programming but can’t drink the koolaid.
I haven’t found a company yet that meets my energy. All I get is people “excited” to be working for their company because they are “changing” the world. It’s marketing vomit.
To be honest I would prefer to have few million dollars in investments and not to work for anyone at all. No arbitrary deadlines, no corporate ladder, no politics.
I just want to write some code, build some servers and play with things. Maybe make something that benefits people in general.
It’s marketing vomit.
An understatement. Do these people actually believe in it ? Or are they just faking it because one has to adhere to company's value ?
Most people are faking it. Being able to spend your time on something that both significantly improves humanity and pays the bills is a rare opportunity.
I don't think that's really true (though the claim might be too general to even evaluate on its merits). The same way that I don't believe most religious leaders are secretly atheists.
I dunno I'm an atheist and I've thought about starting my own cult occasionally :)
I always wonder this. I think many people actually believe the bullshit because they aren't intellectually curious and have spent no time exploring how other organizations might work. This becomes a problem for software engineering because they have nothing to draw on other than their past work. If they haven't worked anywhere other than your current employer, and your currently employer is a dumpster fire, they are going to continue to repeat bad patterns.
I've always wondered what substances people are using, the more that they have to touch that stuff. When I was more naive and inexperienced, I was blind to this, and I also judged it.
Nowadays, as long as the marketers are taking care of it, and they aren't ruining their health, I don't care what they're taking as long as it's not meth.
To be honest I would prefer to have few million dollars in investments and not to work for anyone at all.
This is possible, especially on a tech salary. Have you heard of the FIRE movement?
Of course I have. I do make good money but not $500k.
I’m hoping to increase my net worth by few millions in the next 10 years. Getting close to my first one.
I might grind and go for a big tech job, but it needs to be remote.
I then plan on either working an extremely laid back job where I put in 10 hours a week and collect a salary without giving much fucks or doing something exciting that might not pay so much.
Maybe I will find something along the way that excites me.
In a company whose business is software-mediated (which is basically all businesses these days), there are a bunch of people who are excited to be part of the journey… and a bunch of tech people who have the power to actually do things because their hands are on the keyboard and they can make the business change.
I know which group I would rather be part of.
Given that being paid to do things is going to involve working for some sort of business, I’d rather be in software development for such a business than in marketing or sales or HR or operational support…
No, this is being realistic. Time makes the rose tinted glasses go away.
This would be the same with another career.
It doesn't mean he does not like what he does, just that he sees the reality of working in an organisation.
I don't know. I've been doing this for over 30 years and that seems far more cynical to me than realistic.
I've been doing half of yours and I found that the advise is more realistic and I'm doing exactly all the points he listed but still love my job.
To some extent presenting a cynical affect is seen as intelligent, or “cool”. The poster claims they like the work, so I’d just take them at their word.
They might just have a different perspective than you. I complain about my job a lot. People say to me, “Wow, you must absolutely despise it.” The truth is that if I absolutely despised it I would have left a long time ago. I just have no reason to talk about the good parts. I focus on problems because I want to improve on them.
I focus on problems because I want to improve on them.
Does this work, though? Does the complaining lead to improvements?
I'm posing the question as a challenge, and also out of curiosity. And I'm of the school of thought that it's necessary to acknowledge reality, but, complaining to the point where people think I despise what I'm complaining about may indicate that another approach may be necessary (such as finding practical solutions and giving yourself options that you can test out).
Apologies if being presumptuous.
harsh reality is that 80% of humanity works a dead-end/awful/not wanted job just because bills. IT is a nice bubble in which you do something you are mostly passionate about and you get paid well. I'm not saying "we got it good so don't complain" but sometimes is worth to analyze the situation from the perspectivo of an outsider. IMO i can do whichever tech job, the more i dislike it the more i need to be paid, that's all
Pretty much any job I might have enjoyed more, if it's not a lot of fancy words for "become a celebrity", will look like minimum wage compared to software engineering. Even when it doesn't, pre-AI software engineers were aggressively stalking around the corners of dark alleys to cut the wages/number of seats of that job.
Most other lines of work guarantee poverty or are a riskier gamble with worse prizes and worse loses.
You want to be at the top of the titanic looking down at those swimming to what's left of the upper deck, not rearranging chairs seconds away from being underwater.
Big boomer energy here: it's called work for a reason.
You don't have to enjoy every minute on the job. It's not likely that you're going to be working on passion projects every day. You're not even going to be intellectually stimulated by the vast majority of tasks you will be given. You need to get used to the fact that almost every job as a programmer is probably going to be working on a system that retains eyeballs on screens, counts something, or shuffles around forms.
When you do this for twenty or more years it gets pretty boring. Where are all of the data structures, type systems, formalizations, optimizations, etc? Taken. There are a few people who get lucky enough to have jobs where they can work on things that interest them, where they get to work on hard problems that get them out of bed and plague them while they're in the shower. But they don't leave those jobs and there aren't exactly a ton of new ones being created either. Unless you're lucky enough to be in the right place at the right time to get into one of these jobs, you're more likely to be sitting in meetings and filing JIRA tickets.
Cherish the times when you do get to work on a project that piques your interest. It can happen. But it's rare for it to last for most people. You have to sustain your interest and curiosity in other ways. And it's totally fine if it's anything to do with not-programming.
Meanwhile, on the job? Do your best, show up, be nice and professional. You'll do fine. You're here to clock in your time for money so that you can do other things that you actually like: reading books, spending time with family, doom scrolling, etc.
When I was in college I had a professor who joked that her standards had gone down over the years. Nowadays, her only criteria are: "no criminal record."
Maybe it's just a joke and we don't need to get that cynical, but I think that in the end, enjoyment of the work comes from: whether you can find some creative process in it, and whether you like your coworkers. I think this is the optimistic way of looking at "work is called work for a reason."
To that end, even plain-old programming beats a whole lot of other fields. But to think that we should be drinking the kool-aid and all is definitely not going to stick for the vast majority of us by the second or third decade. I certainly enjoy my job, even though it's just "work."
My professional life and mental health definitely improved when I finally accepted this in full. Whereas at my previous job, the entrepreneurs sold everyone on using the tools and languages of their choice (and sacrificing for compensation in a big way). Noble attempt, perhaps, that may have worked in a different time and era of tech, and under vastly different macroeconomic circumstances. But ultimately, it should not have been surprising, in retrospect, that no one would do any of the work-work that it would've taken to make the company work.
It’s not healthy to have this much disdain and displeasure around your work.
The disdain and displeasure is a result of experience. Of knowing what needs to be done and not being allowed to do it.
The right way, the wrong way and the Army way
Usually, the problem is the sort of people who get promoted into mismanagement. They were good at "people skills" (and all too often - their only skill is sucking up to their boss) and bad at programming. This is a systemic problem that I have not seen any sort of possible way to fix in all the decades I've been working (or visiting dad's office when a youngster). If you could find a way to ensure that only skilled managers get promoted (and incompetent ones fired), you will fix Capitalism. No more Enrons. No more Innitech.
It's a self-perpetuating process though, since the productive, skilled workers are by definition spending the majority of their time learning and doing productive things, while the remainder have the majority of their time freed up to play political games and elect more of their own political kind into leadership roles. That tends to increase the workload of the productive people, further pushing them away from the nexus of decision-making as they're too busy keeping things running. Eventually a crisis occurs in the top-heavy organization (or society, even). The doers burn out or leave, only demanders remain, and everything goes to shit.
Perhaps worker-owned companies could help with this, but I'm sure that the time investment imbalance dynamic would still be an issue to contend with.
I actually read that he is enjoying his job and has a healthy attitude.
Aye. Sounds like there are no illusions and a "lets get it done so we get out at 5pm sharp" attitude.
The "I love coding and need to stay to 8pm every day because we're going to change the world!" is insufferable. Hit whatchu gotta hit, don't play the games, and push the release out the door. Then get out there and live life.
nah, L take. Have a life.
I remember going to hackathons and wanting forced timed experience to build anything. I remember going up to the companies that wanted you to build on their stuff and being surprised at their substandard APIs and how lackadaisical and unmotivated those engineering representatives were, I just didnt understand. A fortune 500 team just hanging out a hackathon with no capability or interest in providing real support?
Now I think back and I realize they just had other things to care about
The hackathon and job could be fulfilling, their DIY projects at home were more fulfilling.
Their entrepreneurial endeavors were more fulfilling.
Sure, they could be totally checked out and burned out too.
But it doesnt matter, set boundaries with your job because that definitely doesnt matter.
I used to think like this, but after getting a wife and kids, there’s just no way a corporate job can be continually rewarding like you describe.
Everything is always mired in unpleasant bullshit and emotionally detaching like the above poster suggests is the most pragmatic way to handle work.
I’ve lost all desire of proving myself and working on interesting problems, because at the end of the day, I’d just rather spend time with my family and do fun personal projects. Work is work and it will be never live up to an idealized concept that you have in your head.
Weird takeaway, I thought the comment was brilliant and spot on! 30 years here too!
It absolutely might be too late for a career change. If you're paid well, and have come to rely on your income, staying put is likely your only realistic option.
Spot on! After 16 years, I'm looking to get back to academia and do a PhD. I felt like I don't enjoy what I'm doing for far too long, even though I changed jobs about 8 times.
I don't think it is reasonable to expect to truly enjoy one's job. This seems like a luxury that some people in certain fields might enjoy, but most of us tolerate or hate our jobs and wouldn't do these activities by choice.
Don't mistake zero-fucks with zero-cares. Staying cool while keeping your sleeves rolled up working on fixes is an absolute life skill. Knowing it's always "Same shit different pile" is maturity, not resignation. Working hard because you are a valuable engineer doing a good job, despite knowing that the world is full of chaos and nothing will matter in 5 years is called Professionalism.
Get paid, invest, be chill and fun to work with, enjoy your family and friends, go fishing or something.
Maybe... But isn't your view also very dismissive of their experience and the constraints and context of their experience?
By far, most companies above a certain size do not operate in a way where these principles do not apply.
WAT? Seriously? Career change?
Your parent post is on-point. You can be passionate about your job and still do the things that he said he does.
You're gunning for absolutism while parent's post is realist.
I love my jobs (yes, all of my employers) but there are few meetings that IDGAF but have to be there because of many reasons. I muted myself and do something else.
I used to be an idealist but I slowly changed my approach because I realized at the end of the day, I'm dealing with human beings day-to-day.
I feel bad for the commenter
yeah the post where you don't even directly address him, its just teeming with compassion.
Working for any organization comes with its downsides. Pretending like they don't exist and gaslighting someone who's come to peace with them for long-term job satisfaction comes off as pathetic to me.
Came here to say the same thing, but a lot more angrily and a lot less eloquently. Thanks!
It's a job, trading labour for money. Enthusiasm isn't a requirement, it's not an acting job.
Ever hear the term "mid life crisis"? It exists because people around 40-50 - that is 20-30 years into their job they realize they have been doing the same thing and it is getting boring.
While it isn't too late to consider a career change, I'm not sure that is a good idea. For some it is, but many stay - particularly in tech - because they can make a lot of money and thus afford some hobbies that are not boring. Often this is overall your best course in life: find a hobby you enjoy and keep doing your job.
Obviously everyone needs to make their own decisions.
I love writing software and building things that solve real problems, but it’s astonishingly rare to do this as employment. Yet, you still need income as children don’t eat for free. So for the other 90% of us you have to make a choice:
* Go to work knowing you are probably not productively writing software and just accept that reality for what it is: staring out the window while other people listen to the sound of their own voice out loud all day long. And, you often have to drive through lengthy traffic to relish in this experience.
* Write software outside of work at cost to your marriage, time with kids, personal finances, and everything else with work life balance.
* Go do something else.
Agreed. I'm "only" 20 years into my career and, while it has ebbed and flowed, it's also something I love and am thankful I get to do for a living.
It’s never too late to consider a career change.
Absolutely, but the huge difficulty is finding a place where the grass is greener. Nearly the whole world is quite equally shitty, it is just the kind of shit that you will see at the various careers ("septic tanks") differs.
How many people in the world (, software engineers or not) actually have the privilege of enjoying their jobs after 30 years?
I'm not that guy, but I don't have to like it. I'm not skilled at anything else and I couldn't make this much money in any other career.
Most people will never enjoy their work, but I can dislike my work while being far better off than most people ever will be.
Thanks for sharing your valuable point of view. Unfortunately TV shows, media and being a nerd at home while everyone else was having fun created the myth of the brilliant software engineer that is saving the world through coding - in some cases it was therapeutic or a way to be "different".
Reality is that the software industrialization (which happened after 2000 I believe?) didn't give a damn about those nerds or 10x engineers or whatever: they want decent people that can be replaced as needed. Not necessarily in a cynical way but in a way that every other field works - employees should not become a risk. When that happens, you as a manager have failed miserably.
Yes that's a fair perspective. They wanted fungible staff. The only way to add personal value is to be as non fungible as possible which means being an expert on niche things that the fungible folk aren't. That is usually domain specific concerns and intricacies.
But really I haven't changed the world. I've made it a lot worse. I caused the loss of thousands of jobs. I took money from bastards and con men in return to make things to make the world worse. I celebrated the demise of competitors and their staff going hungry.
And I only did this all because my official qualification didn't pay as much.
At least I'm honest.
That is a choice. Not criticizing you for yours (and bonus points for honesty), but optimizing for money is not the only game in town. Plenty of software engineering work makes the world better while paying enough for a very comfortable life. Not FAANG levels, but good money. My 2c.
Yes I agree. I don't make FAANG money but I live comfortably. I think what is important is optimising for a fair balance of happiness in life, which despite my negative outlook here is pretty damn high and taking home enough cash to enable you to do what you want to do before you drop dead.
I'd be more invested in something which improves the human condition but that's a 1 in 100,000 job. Perhaps I should have done biochemistry or something at university.
Hey, if it makes you feel better, a lot of biochemistry research ends up being completely meaningless fluff that is only published to inflate the author's reputation, but will likely have zero effect on the real world.
You can be cynical about anything if you want to :)
Hahaha thanks for the perspective. I feel a little better now at least :)
I'd be more invested in something which improves the human condition but that's a 1 in 100,000 job.
I think the ratio is much larger.
But consider that market forces do work:
Since a lot of people want to do such a job, the salary will be quite low (i.e. so low that there won't be a long queue of people who want to do the job for such a low salary; the salary will just be high enough that the positions can be filled), thus these jobs will typically only be attractive to people really who want to put their money where their mouth is (i.e. their willingness to improve the human condition is so huge that they are willing to accept such low salaries).
On the other hand, the salaries of "bullshit jobs" or jobs where you do evil things will be much larger, because otherwise the company will have difficulties filling the positions.
This. I've learned that I can't optimize for income, because typically it means I'll be doing work I dislike, or working for a company I dislike. For me, there is no amount of money that can balance that out. I'll prefer a position that pays a bit less but that I enjoy over one that pays excellently every time. To do otherwise ensures I'll have a miserable life.
Others can and do differ, of course. We all optimize for what's important to us.
Disagree there is a choice.
We all have money pressures. It is ALL MOLOCH.
If you think you have a choice, then count yourself lucky that your life ended up in a position that allows that illusion.
You've obviously hit a sore spot for some people.
The system is built to capture value (not create it) while externalising as much damage and cost as possible.
The sooner one accepts that the less deluded one needs to be. There's no company 'mission'. The only mission is try to find a way to survive and prosper under hegemonic capitalism.
The system is built to capture value (not create it) while externalising as much damage and cost as possible.
What system?
The System. US. We are MOLOCH.
The only mission is try to find a way to survive and prosper under hegemonic capitalism.
How true this is depends on where the money is coming from. Founders at a bootstrapped company may actually believe in their stated mission. I've seen it. Once investment money gets involved, sure, it's all about the exit. Even the founders may be legitimately confused about this, which results in a lot of mixed messages. Professional leaders who have held executive positions at large enterprises have zero illusions and will probably give it to you straight if you ask them one-on-one.
It's worse than "the system". It's natural human behavior. Take as much as you can for yourself and your friends/family, push the costs onto everyone else. Altruism only happens in proportion to the extent to which it's felt.
Humanity has not yet invented a system that discourages this behavior effectively in the presence of abundance and wealth.
Your grandiose language (I've seen things you wouldn't believe, etc.) means you aren't as self-aware as you think you are.
Sorry I didn't think past listing the horrible things I'd done. Perhaps I should have stuck my business hat on and gone a bit more Cervantes to fit the mould of startup culture?
"One man scorned and covered with scars still strove with his last ounce of courage to reach the unreachable stars; and the world will be better for this."
Urgh no I'll stick with reality.
At least I'm honest.
For what is worth, I appreciate this last bit and I think many others do, too. It's depressing to see a person doing all these things and not seeing through this.
A "nerd" will be under-utilised and probably dissatisfied in most companies. Most software projects require developers with a level of knowledge that is "industry standard" - being able to write good-enough code in a popular language/stack with a popular IDE and tooling used in a company-specific way. Nobody would care about your vim customisations, the lock-free data structures you implemented, or your deep knowledge of compiler optimisations.
I think this is spot on and that distinction deserves to be in the education of present and future programmers. It's at the root of the different terms (programmer, SWE, computer scientist, developer) and it's not unusual for a role to demand more than one of these types of behavior. But, it's often disheartening to those who would rather spend their time daydreaming in math.
Reality is that the software industrialization (which happened after 2000 I believe?) didn't give a damn about those nerds or 10x engineers or whatever
That's only true for 95% of companies, not 100% of them. But if you're really in the 5th percentile, you shouldn't care about these 95% anyway. I've been lucky to experience software companies that really care about exceptional engineers (and have proper business incentives to do so), and it truly has been the best place to work at as a software engineer.
Unfortunately TV shows, media and being a nerd at home while everyone else was having fun created the myth of...
Well, yeah. But how many real careers are accurately portrayed in TV and media, or closely resemble doing $Stuff as a hobby? I'm thinking somewhere between "zero" and "Gell-Mann Amnesia".
Point 5 - meetings are great if remote. You can sit there muted on a zoom call for hours tweaking with your bike or playing games on your other computer.
You dont have to tell people about it...
What is valued is presence and contributions. That doesn't necessarily require attention for the entire meeting. I'm not going to live forever so I would rather expend that wasted 80% on something that I value. The outcome of the meeting is always the same!
Sounds like you are part of the problem
Unlikely. I don't create meetings. I get invited to them. They are mostly unnecessary and have a net negative return of investment. I mean lucky if any of them have an agenda, minutes or an action and rarely does the facilitator actually have any conceptual knowledge of the subject. The meeting exists to service the facilitator's personal value and the naïve process model, not the business, the staff or the customers.
Why just dont attend them?
Im invited to like 10 of meetings each week
Nobody expects me to attend those where im not really important or need to discuss stuff
Because that means I have to justify not being a "team player" then. And I can't be bothered with that. I'm not creating conflict for the sake of it.
Just stop attending then and do actual work and raise it up with whoever you report to. You are just as guilty for blindly accepting this behavior and then fucking around. Either do your job or do something else.
Managers forget to ask themselves if a slack message / email could have done it instead of creating ANOTHER meeting.
And it is your job to tell them to go fuck themselves and stop wasting time
What problem?
If you can’t identify it, then you are definitely part of the problem
I've asked my coworkers to cancel a biweekly meeting that in my mind creates no value. That meeting still lives on, so I don't feel guilty about reading news or clipping my nails while it happens.
Have you asked what value they see in the meeting?
Not GP, but I once asked my engineering colleagues if I was the only one who doesn't pay attention in the bi-weekly all-hands because most of the information is irrelevant to me (e.g. what new marketing strategies we're using). Some admitted that they would do some work on the side, but some also said "well, those people also want to have a chance to share what they did".
I found this remark puzzling and illuminating at the same time. Apparently, for some people, meetings aren't about productivity but about satisfying psychological needs.
I think they decided to end the conversation there and then when I suggested axing the meeting, so I didn't bother. I just show up every two weeks muted and get noted as an attendee on some pointless meeting document. No skin off my back since I don't own equity.
And you wonder why execs are pushing RTO so hard
That's mostly because all that empty office space looks bad and it's worth nothing now.
My retention from any audio is simply better if I’m doing something other than staring at the screen. On meetings that I’ve listened to while taking a walk, I can think back to specific things on my walk and recall exactly what was being discussed, sometimes months or years later. This holds true for doing housework, yardwork etc. There’s some spatial component of memory that wakes up while I do that. It might look like I’m not paying attention to the meeting at all, but I’m actually paying more attention and getting chores done. Win-win.
estimates are always wrong so don't put too much effort into it. What people value is how long you spend making up lies so spend some time on it!
Why people always say this? In my team we have never missed an estimate of what we have planned. I also don't remember it in other projects where team does take time for planning. What is so hard that people find estimating their work?
You can make any deadline if you pad enough.
Which, when you ask enough questions, is what most stakeholders want.
Unless the budget is limited, and estimates have to be "optimized" to meet political goals. At that point, disengage and waste as little time as possible on making up shit.
Careful, available budget will always be spent, available time will always be filled.
For sure, some teams are way better at estimating than others, and I don't think it helps when a team has the attitude that estimates are some sort of corporate bullshit.
No other engineering discipline has this level of immaturity. Sure, estimates in other industries are also notoriously hard, but you don't see this utter disregard for them you see in software. And, I bet you donuts that every "software engineer" here as demanded estimates from other fields and felt angry when they were missed.
"When is that bridge going to be finished?" "When is the road work going to be completed?" "When is my house renovation going to finish?"
Estimates are important. And yes, they are hard, but there is spectrum of skill levels at doing them well.
I think it depends on industry, maturity of team (tenure on that project).
I’ve worked on teams that have exactly your experience. I’ve worked on others where they could just never hit the mark. Skills and experiences seemed equivalent. There didn’t seem to be a magic bullet reason, just a whole series of reasonable explanations.
Sometimes the spec of wants to be built is just some notes on a napkin with a whole lot of ambiguity.
Sometimes the "estimate" was already predetermined to meet some arbitrary marking goal.
At most companies the stakeholders barely know what they want. They provide a vague idea of what they want, and you give a wild estimate (referred to as a Silly Wild Ass Guess). Knowing all of the details of the problems that one is going to encounter in their old legacy system is basically impossible without spending a bunch of time up front, and you always discover more when you start writing code, so it is best to just start and iterate until you have enough of what the stakeholders want and you move on to the next disaster project.
Maybe you are getting good quality requirements and / or have a system to work on that is somewhat easy to reason about.
Requirements are often hazy. Pushing back on that is good, but if the response is "do it anyway" then you either quit or handle the uncertainty as best you can. The latter makes estimating hard.
If you are going to have to depend on third parties (whether internal or external) that is another thing which can torpedo an estimate that was made in good faith. There would often be too much uncertainty in that situation to be able to accurately account for it in an estimate.
"estimates are always wrong" is obviously an exaggeration - the whole comment is written in that spirit.
Some problems I often see:
1) The people estimating the work aren't always the ones doing it.
2) Engineers are optimists, estimates are often best case.
3) Not enough padding added to estimates (see #1 and #2.)Are you always working on similar projects? Unknown unkowns are what gets you.
"we have never missed an estimate"
After 35+ years of software development, you are either lying, incompetent, or worked on exceedingly trivial software. Sorry to be harsh, but I can guarantee you that if you were given a significant software project, asked to estimate and then deliver, that the vast majority of the time your estimates would be wrong.
It's easy on small teams on small products. Eventually, as capitalism demands eternal growth, they grow to the point that the complexities and hack jobs that were used to deliver previous estimates impact them. Then no one wants to turn up with a realistic estimate. Eventually all the estimates become lies because of the incalculable complexity of the estimation process that results from the complexity of the product and your options are usually to try and lie and deliver late, but not later than other teams in the org.
Every org I've worked for ends up like this.
There is a lot or intellectual dishonesty out there. It used to bother me. It doesn't now. I just don't partake in it.
What is so hard that people find estimating their work?
Unpredictability for any new work. Even knowing my codebase well, I sometimes forget how changing some piece of code will require changes in other places. And without having done exactly the same work before, I cannot know how difficult it will be and how long it will take.
Dependency on other teammates or other teams. If another team is building something that your work depends on, you have no way of knowing when you'll be finished. If the code you write needs to be reviewed by other team members, and then you'll have to incorporate the suggested changes, this makes it harder for you to say how long something will take.
What is so hard that people find estimating their work?
The central difficulty and huge part of many programming projects is actually the "unknown stuff" that is insanely hard to estimate, be it
- requirements set up by users are often very vague
- interacting with some very complicated third-party library/software that takes years to only understand the basics of
- many programming tasks are unique, thus you have never implemented anything remotely related, and thus also have hardly any idea where the difficulties might lie
- the new software "has to behave like the old one". In the old software, there exists an insane amount of corner behaviour where nobody has any idea why it was introduced, but the users will at some point complain if the new software behaves only a little bit different in such an obscure corner case
I'm amazed to read this. I'm pretty sure that I've never seen a reasonably accurate estimate for a nontrivial task in my entire career.
Here’s my one key observation after 35 years:
Whenever someone refers to planning as “lies” and whines about “politics” … you can be sure they are a difficult person who blames everyone but themself.
Whenever someone refers to planning as “lies”
I believe it's all about size. Small tasks can be estimated fairly precisely, with 30% margin maybe. But some people extend this logic to huge projects and this simply doesn't work.
I give you example: I was once asked to estimate the amount of work needed to migrate a huge org from on-prem to one of the public clouds. Without even knowing what kinds of app they were running. I said I can only do a very rough estimate and there are too many variables to be precise. But they insisted and hired someone else to do this job with the precision of half-day!
Needless to say, their estimates were too optimistic because they could only include what they knew. By design, they couldn't measure the things they know nothing about because these issues haven't appeared yet. Last time I checked, they are still migrating and I have a feeling they will finish around the time I had originally planned, that is the second quarter of 2024.
So you're saying you didn't get the job and the people who did are getting paid a lot more than they originally bid? :)
No, I quickly moved to another team and watched my colleagues get fired or quit one by one as they couldn't keep the estimates done by someone else under pressure. It was a surreal experience.
When you estimate small tasks, most of the estimates will be accurate, but once in a while, you'll overlook something and a small task turns into a big task, e.g. you need to switch APIs or the customer wanted something that sounded similar but turns out to be much more complicated under the hood. So it's not a Gaussian distribution, it's that once in a while a task blows up.
In my experience, large estimates are only ever Rough Orders Of Magnitude. Our teams do not pull any work in to be done unless they've broken it down to the smallest estimated components. Anything with a large estimate is inherently inaccurate and not ready to plan around.
The situation you described seems quite broken
"politics" just means "large groups of people making decisions together". People love to complain about it, but in reality it is the one tool we have to steer large organizations.
"once God crapped out a 3rd caveman a conspiracy was hatched"
You can't have large groups of people making decisions without politics, and anyone saying otherwise is kidding themselves. You either play the game and pick a side, or someone picks it for you and you get what you get.
Keep in mind this is entirely separate from ruthlessness or backroom deals; this is just the way of things with large groups of people.
Acknowledging the ubiquity of politics in organisations is not whining. He only offered a way to deal with it for those not interested in playing the game, or who are not very good at it.
The poster is referring to estimation, which is different than planning. Estimating is hard, and requires a many people working together. It can be done for a group, but not for individuals.
In many places estimates are actually lies. There are even plenty of companies where realistic estimates, and well planned projects will get you sidelined. These are often places that reward for fire-fighting rather than planning, and where your value is judged by how busy you appear to be rather than how efficiently you work.
It's important to understand which kind of company you are working in, and if you understand that, then you can adjust your behavior appropriately, and succeed within the environment.
I'm happy to be working in a place that rewards for planning, but I've worked in places where detailed and accurate planning was punished. Oddly enough, this division is surprisingly disconnected from whether the business is successful or not. A good business model will cover a multitude of technical sins.
I think you'll find I blame myself for these issues. I just do not deny that they are issues.
I blame everyone else and myself equally.
But I'll stop whining about politics when I'll stop witnessing well-behaved but incompetent people turn projects to failures.
I don't think all of this applies in a small outfit. Some of it, sure... Politics is less of an issue in smaller companies. Disconnecting is perhaps actually harder in small companies, idk. Incompetent people can't easily find a place in small companies I reckon, unless, unless everyone is incompetent, in which case the company won't be around for long!
Strongly disagree. The smaller the company is, the more political it is. Because now there's no layer to appeal to or to inject sanity; it's the way of the owner or the highway. Being on the right side of the owner is the most important thing and if you're on the right side, you can be as incompetent as you want (see: son of the owner is an idiot, but is the second in command).
Maybe you're right. If so, I guess I am one of a lucky minority that buck the trend!
Sorry you’ve been burned by nepotism and incompetent leadership. That’s not the root of politics though. Politics is about decision making processes and power dynamics that emerge in large groups. This becomes difficult regardless of competence because power and control become decoupled due the bandwidth limits of single humans, and so the methods of influence and direction become more manipulative and/or more draconian.
depends on the small org. large orgs have a lot of people and a lot of personalities, processes, HR handbooks, you name it.
small companies have a handful of people, and if there is a clash then you're gonna have a bad time. in some ways this is good since you have only to lever or negotiate with 2-3 people, and can get facetime, but if you're on the shit-list it's not gonna happen.
You make a good point. There have been times an HR handbook / department would have been useful. At the end of the day it's a choice I guess, which kind of org you work in. HR departments can also be a bad presence, depending on what is going on for you at the time.
If anything, politics is MORE of an issue in smaller companies, but it usually plays out differently. Be aware of what's going on and _be involved_ or prepare to get blindsided at some point.
Fair points there. Although I have worked for a number of very small companies (startups) that have been successful and totally incompetent, at least one to the order of having the CEO threatened with jail time by the authorities.
I love that I work somewhere with no incompetent people (or rarely) as it makes working a lot more fun. You spend most of the day solving real problems.
I had a couple of jobs like that. I looked back and worked out they weren't real problems. They were problems invented to sell solutions for that made money. Supremely productive but alas pointless too.
I eventually developed a philosophy of passive capitalist nihilism. I can't change anything meaningful so I will use the accumulation of capital as a coping mechanism to deal with that.
There are no “real” problems if you have water food and shelter and your family and friends are safe etc. Everything is consumerist driven. Driven by desires.
But my current job they are building something worthwhile and I believe a lot of companies are. But the FAANGs might feel less like that. But let’s say you work for Splunk or Shopify or a government portal or writing drone software or whatever I think it is useful.
Desires are real though.
It happens sometimes! I've been there. Enjoy it while it lasts.
That is how I feel in my current team/department - but I always worry that if you don't know who the incompetent person on a team is...
Point 10: don't this makes you a target? Being part of the tribe might be painful, but getting thrown into the jungle alone is a hell of a lot worse.
It makes you a target if you position yourself as a faction of one that tries to influence decision making. That's a contest you're not going to win, 99% of the time.
If you just go with the flow, and are reasonably competent, changes in faction dynamics usually wash over you. You end up taking orders from someone else, every now and then, but if blame needs to be pinned on someone, there tend to be juicier targets.
Exactly that.
No, if you're competent and have good soft skills, you can survive a purge even if you did not take a side.
I was hired at my previous job by a departing manager who just lost his struggle against our new manager. I managed to finish my job, extend the solution to other teams (as mine went from 12 devs, a handful of Indian support, an Indian QA and PM, to a dev and two level2 support). It was probably my most painful job yet, I regressed, I didn't really 'finish' in the sense that it lacked documentation, good CD pipeline and minor tweaking to make it more efficient, and I hated the last months with my whole being. But politics didn't touch me.
Here is something i encountered, sometimes higher ups will put arbitrarily deadlines and act like the entire business depends on you meeting that deadline for a project and after that deadline passes no one seems to care that much about your product, they even allow you more time to do it "right".
That some top-tier management practices you experienced there. I expect your productivity*quality sky-rocketed.
Spanish theory of management! The more they push the more they get!
How sure are you they are incompetent vs. just not giving any fucks/disconnected from the job and there to get paid (it's objective one after all!)
This seems a little inconsistent to me.
Is it really their fault if the industry says they are qualified and gives them a job when they are incompetent?
Well the people who don't give any fucks want to make their life easier so they do a minimally competent job and are usually supremely skilled avoiding pain. The disconnected people don't actually do any work at all. The incompetents cruise in, full of ego, poop everywhere and expect everyone else to clean it up and take responsibility for it. I don't mind that job because it's an open ended task. As for it being their fault, no it's not really, you're right. But management need butts on seats apparently so standards will be reduced until they are full.
Also many incompetent people, when faced with enough pain, will turn into competent people and eventually stop giving a fuck too.
Wow I’m sorry, it seems like you really had a bad experience.
I had good ones too. But they didn't pay as much.
Point 10 - The only soft skill is politics. Any sufficiently large organisation employs many politicians. The best way to deal with politicians is analyse the factions and stay neutral. No one can drag you to their side then.
Staying neutral does not only have the meaning "be diplomatic" or "don't give an opinion", but can also mean "treat all factions equally", which includes the case "treat all of the people who make political attempts with open hate". This way, also no one can drag you to their side. :-)
Definitely correct. I'm glad you extrapolated that point.
Nothing matters so don't get too wrapped up in it or upset about it.
The "it is what it is" way of looking at things, I wish more people in this industry would embrace this.
It more probably won't get one to 600k yearly comps while working at FANGs, but at the same time is a lot more healthy for one's psyche in the medium to long term (and for the psyches of those close to that person, like family and very close friends).
Learning point 9 early will save you a lot of pain.
I'd add this: Care about your job, do your best, learn, grow. It'll serve your career and it'll serve your happiness/satisfaction.
HOWEVER, accept that things will go wrong/dumb decisions will be made, and it's not all up to you to fix. If other people make dumb moves, you don't have to die on the hill. Let others fail, it's good for them too. I promise you that nobody will actually care after it's over. It's not worth the mental agony.
Point 9 - Eventually you do become able to disconnect from your job. One day the fucks just run out. Embrace that early on and save yourself a lot of stress.
This is the most important life lesson anyone can learn, but I think it can only be learned by going through a flaming dumpster fire that burns all those fucks away.
You can't get that confidence and no fucks given attitude on your own, at least not for most people. You have to go through the shit and earn it.
Jaded and cynical as hell.
Money, Assignment, and Team — if any of these two are shitty then find a new job. But be honest with yourself.
Point 4 - incompetent people. They are great.
I used to think this too but it rarely works that way in reality. Why? Because, as Roger Sterling put it, "Half the time this business comes down to 'I don't like this guy'".
Incompetent people survive because, for whatever reason, they're liked that decision makers, who may themselves be inccmpetent. Or it may be they're just similar in outlook, background or interests. It doesn't matter. Or they may be politically savvy enough to take credit for things that work and deflect blame when they don't.
I've seen teams spend a half on something, not launch anything, make a post about "we learned a lot" and get praised for thier "achievements".
Point 5 - meetings are great if remote.
For many people, myself included, this is still incredibly distracting. You can't switch off entirely.
Just to comment on incompetent people. There are kinds of incompetence. It also makes a huge difference where in the hierarchy they are. Incompetent boss will not let you save the day, but will make you take the blame, for example.
Here's an example of incompetence I deal with every day. The head of R&D department either pretends not to understand or is genuinely this stupid as to engage in the following process over and over:
* We release a program with many defects due to the short development and testing cycle, but especially due to poor (or missing) planning.
* Customers complain they cannot achieve what they want using our program.
* R&D lead bravely rushes to "extinguish the fire" by adding new feature to work around the customers' complaint.
* Because the feature was never properly planned it creates multiple new issues while coming late to the testing stage.
* We burn past the deadline, and eventually have to release still half-baked.
* Customers complain again...
There's no place in this scenario where any of the underlings can swoop in and save the day, because saving the day would be to tell the R&D head that he needs to go through due process of planning his contributions and coordinating with other department heads, esp. the QA. But nobody can, because this will be judged as insubordination and violators will be fired. Over half of the underlings are on work visa, not to mention that the company is almost exclusively filling its niche. So, nobody wants to speak up out of fear of being fired.
On the other hand, such incompetence only lowers morale, leading to most underlings losing interest in the subject matter and doing the absolute minimum to hold the job. You'd think it's a miracle such a dysfunctional company keeps sailing... but, I have this to tell you. This is not the first company of this kind I met in my life. All companies of this kind that I've met by the time I've met them were over 20 years old, profitable, big, fearlessly looking into the future...
"It's nothing personal, it's just business"
Truly the love of money is the root of all evil...
I think that one very important issue got left out: always be learning. The colleagues that ended up having to change careers were ones who refused to keep current with technology. Or who treated education like a vaccine: "get it" once and never again. "Learning how to learn" is probably the most important skill one learns in college, yet it is treated as a side issue (if at all). So many tech stacks have ended up on the "dustheap of history", yet we have to constantly learn new ones.
For a software engineer, these are great points to follow if the goal is to be the incompetent person on the team in a few years...
Personally, while I find myself frequently in too many meetings or spending way too much time with email, or $DEITY, git rebasing to satisfy some power-hungry gatekeeper it is the little side projects that save my sanity. While many are the equivalent of throwing paint on a canvas, it is cathartic. So maybe the one good thing to come out of the google mgmt style that everyone seems to have copied (not the side project bit, all the other garbage) is the 20% time.
So much truth in such a dense format. =)
The only soft skill is politics.
This statement is void of content - virtually a tautology.
All soft skills are politics. Politics is large in scope. You do a favor for your friend? That is politics of the "good" kind.
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.
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.
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.
"I want you to build a document management system, how long will that take?"
Uhhhhhhhhhhh....
It will take 2 months to gather the actual requirements and be able to do an estimate.
This guy consults.
From my experience, the two months of gathering requirements will be more valuable than developing something from zero requirements. Whatever you code with always be "wrong" because with zero requirements there is nothing to test against.
Fork an existing one, slap your name and logo on it. 2 points.
Exactly. We'd love it if more people did that with our document management system. (https://github.com/formkiq/formkiq-core)
"It will take me X weeks... to come up with a reasonably accurate estimate."
the correct answer is 'yes'
"This is git. Have fun!"
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 like the store metaphor.
Shopping list is set and I should be in and out in 15 mins but it turns out there is no ketchup - so do I go to another store to get ketchup or mustard will do. Product owner my Girlfriend has to decide because she is doing the cooking and will present it to customers our guests, and she knows if they like mustard or not because she talks to them more often than I do.
But yeah going to another store might make dinner late and I cannot know this until I actually arrive at the store that there is no ketchup on the shelves.
Its a good metaphor also because if you have an appointment in 20min you would never go to the shop 15min before. Yet managers will force you still out and to the shop because of your time estimate.
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?"
Teams definitely refine and alter estimates as new knowledge of the problem space is discovered. It’s a management (and team) failure if this does occur.
Also, on the negotiation side of time it will take, I absolutely know for myself that I can code things fast and functional but a bit hacky, or beautiful and elegant and will take much longer.
The negotiation should be about when to do which.
At a higher level, you put your teams together within their temperaments in mind and match that to the work.
Some code will be a nexus of changes and interaction with other code (invest early), and some code will get written once and never seen again (go fast and forget).
I've streamlined the process, and just say that anything will take five days to complete.
Estimate are for accountability. It's for team management. That's why middle management shouldn't have access to estimates imho.
The issue everyone is skirting here about estimates is the unknowns. Letting management know what the unknowns are and how confident you are you can resolve them is just as helpful as providing an accurate hour estimate.
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.
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 here (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.
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.
It's called "estimation" because it's not supposed to be precise.
Of course the only way to obtain a precise measurement is to start the clock and do the thing.
And yet in the politics of a company, an estimate becomes fact, and then if you don't meet it they are angry.
Am I the only one who watched star trek?
Estimate, multiply by 4, give the number.
I was always told to multiply by pi. Results that are not round numbers look more thought-out.
Much like estimates, pi is irrational
And pi squared if it is a new team doing something new...
I dont know if you are joking but when managing i do exactly that and that work (with a factor of 3 to be precise, with most people, some aldready take that into account). Works also with myself, i askmyself 'how much i think it will take, i double it and i assume half the day i will be bothered by other unplanned things'. It work remarkably well especially for longer projects.
It will take 4 units of time, time units are subjective.
There's a three-pronged approach when dealing with it:
- Pad.
- Communicate risks.
- Communicate assumptions.
Then when assumptions are wrong, immediately communicate that this will change the estimate. When risks hit, communicate that a risk hit, and whether or not you can absorb the impact in the planning. If not, communicate the expected delay. Pad that too.
Communicate, communicate, pad, and communicate.
(Padding, BTW, may feel dishonest, but it isn't. It is making the assumption that a certain share of you risks will strike and making allowances for that.)
If you still get in trouble for missing estimates, pad more and communicate in writing. Then when people start blaming, you can point to the emails sent. To their/your boss if necessary.
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.
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!
There is a basic level of standards.
I agree with you, and it's very simple to define such a level: use as much discipline as you need to ensure shipping features at an acceptable rate in the long term.
Too much polishing lowers your release rate. Too little discipline will hurt the "in the long term" part.
Thats a good way to put it. Shipping value rather than features though. Which is represented as long term shareholder value, but within some kind of ethics (don’t fuck the customer type stuff).
Thinking in terms of value could mean you sometimes suggest weird things like removing features, cancelling WIP (sunk costs) etc. when appropriate. Or spending way more time polishing than seems necessary or conversely getting something out that looks way too quick and dirty. There are cases where no tests are OK despite what I said but usually MVP stage stuff where no market fit exists yet.
"Places that value that shit speed at any cost eventually go bust"
That has not been my experience...
A lot of negative points, indeed, but the first priority is to ship new functionalities. If he was the only one focused on shipping, while you others loved to get lost in useless architectural debates, he was the best candidate to team leader.
But the functionalities don't work and generate customer support load…
I should perhaps mention the time he compiled a binary on his machine, committed it on github and went on vacation. And then we couldn't fix the bug that needed urgent fixing.
Corollary 1: clean, maintainable code is only important when you have customers expecting maintenance.
We do have customers yes.
Corollary 2: in the Real World (tm), the alternative to technical debt is getting out of business.
You're defending this guy so much… why so defensive? Do you reject the notion that incompetents exist?
You're defending this guy so much… why so defensive? Do you reject the notion that incompetents exist?
I'm not defending him. I'm just refuting that a developer's competency can be judged without taking into consideration, first and foremost, the benefits he produced for the users of his software.
But the functionalities don't work and generate customer support load…
And this is the first issue you should have mentioned! All the rest is peanuts...
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.
don't blame the player, blame the game.
I disagree with this statement in general. Institutions/nature (the game) cannot be held accountable. Persons can be. If we want to change the world, it starts with changing the behaviour of individuals, slowly changing the institution.
The person who needs to change their behavior is the hiring decision person. The player is just making the best of his situation. The fact that the game is running means the most likeable person will be promoted, even if they aren't liked much.
The players should cooperate to not end up with someone bad for the players being promoted.
When there is no rulebook, definitely blame the players.
without the player there will be no game. blame the player.
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.
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.
If they aren't the best developer but realize that then it isn't a problem - it's when you have someone who is terrible and thinks that they're great!
I hope there are a few in-between steps between "strongest developer" and "actively destroying what others are doing"
Count yourself lucky.
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.
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.
Oh yeah the account is accurate.
At some point I had to use a C library written by him.
Due to segmentation faults I decided to just rewrite it by myself (in less than 200 lines).
He holds a grudge against me because of that.
When I showed with benchmarks that a sleep() in a loop in the main server thread is not a great idea he said "don't fix what isn't broken".
djamn, this is painfull
Maybe thats exactly how management acts in this firm?
They looked at complaints about this dude's behaviour and go "clearly one of us!" ^^
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.
"If you can't change the organisation, change the organisation"
Or change your own perception.
I don’t think this is completely true. There’s a limit to how often you can force yourself to run the interview gauntlet.
Remember Rule 10: Soft skills over technical skills. I'm sure the team lead has some qualities.
The only skill he has is sucking up to his boss.
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.
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?
He doesn't have standards. Last time I had to do with that team, the only test the code had passed was "it compiles".
Surprisingly, it didn't work.
> the only test the code had passed was "it compiles"
He might be really good at type systems!
> The test contained a "return true" before the actual test.
And he could find the same amount of deficiencies in your own code. You can always find something if you search hard enough.
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.
You can always find deficiencies. But some code is objectively worse than other code, sometimes massively so.
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
I do wonder whether this was escalated, to either the previous team lead, some other manager, or just a shouting match in the corridor.
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.
Have you tried changing companies? That sounds like a very toxic environment.
Last time I tried that I ended up in a company that was full of racists… I had to leave in a couple of weeks.
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.
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...
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.
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...)
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.
team of 4 including himself.
They seem to have a lot of spare time and work on toy projects often.
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 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 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.
This is some bullshit that losers subscribe to.
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.
Lego during meetings. Now there's a good idea. I'll take that one away as good advice!
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)
3) Nobody gives a f** about your clean code
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.
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.
I agree with what you wrote, but I've worked with people who balk at even automatic gates. "Pass pep-8, as enforced by pycodestyle" was practically too much for one coworker I had, who, when it was pointed out in review that "the automated CI step was failing, can you please make it green?", would fix like one violation, then just ping their reviewer? And around the mulberry bush we went. Various odd arguments like, "well, my IDE has pycodestyle built in, and it's fine" (it seemed like his IDE had its own, separate, lenient config? … but like, nobody cares about your IDE…?) etc.
At $different_employ, there was lots of thrashing of teeth pertaining to `yarn audit` running against the codebase, and failing people's builds. Some people fought tooth and nail to get it to not fail the build, because they didn't like that their new feature, which didn't introduce any vulns. per se, was failed. Later, other people did much gnashing and wailing over being "confused" because the yarn audit step was red-X, and they were confused as to why it was breaking on their feature branch. It wasn't: it was failing, but marked to be ignored, so the build continued. Other, required steps, were failing. (And were also marked with red Xs.) This was "all too confusing", and it was petitioned for yarn audit's CI step to just "fail" with a green checkmark. You can imagine, I'm sure, how many vulns. were addressed after that point.
I've also worked with devs who are just amazing, and aside from being brilliant in how they architect their code/systems in the first place, … they have a definite tendency to view lint errors as just "oh, oops, silly me fixed" and just Get It Done.
QC is hard.
(Regarding our audit step, too: we also had an ignore list. You could just add the vuln. to the ignore list, and that would technically placate CI. Obviously not the best … but CI didn't demand that you fix whatever the issue was.)
Some people fought tooth and nail to get it to not fail the build, because they didn't like that their new feature, which didn't introduce any vulns. per se, was failed.
Well, here is the problem this introduces. Who is supposed to fix this and which PM's bucket of time does it come out of? This implementation just makes it seem like the answer is "whichever team is unlucky enough to make a PR when it is discovered." The perverse incentives of that are enormous.
You can imagine, I'm sure, how many vulns. were addressed after that point.
This tells me that the responsibility isn't specifically assigned. This seems to be the broader issue, with the audit in the pipeline a managerial attempt to get vulns somehow fixed without doing the work to figure out how they will be fixed and who will do the work.
Someone actually needs to be responsible for it and be given time to do the changes. It seems like this was not done.
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.
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.
Is there such a thing as clean code? What’s perfect now can change at any moment.
New business or acceptance criteria, architectural changes, and other human created obstacles.
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.
the word 'care' is doing a lot of work here.
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.
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.
In my experience no coding standards or cleanliness can prevent this. The only sure way is testing on commit/PR.
I think that's an issue with how people define "clean." It isn't just about surface aesthetics. Think of a cooking appliance that looks "clean" in its design, that might win a designy design award, but accumulates gunk in hard-to-reach crevices because it was only designed to look clean, not designed to be kept actually clean.
Fair enough - it may be that I've never experienced "real" clean code. But I've worked with many good engineers and seen this problem repeatedly. However, no matter how unclean the code is a rigorous test suite will find many regressions.
A modular architecture will prevent changes to one system from breaking other systems.
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.
That subjectivity also changes over time. Just go back and look at some code of your own after a few years.
Oh yes, I totally agree. Some things that I used to write, I would find insane now.
But it doesn't make the problem any less real. At my current job, I think our tests are really bad because they mostly don't test what really matters (also due to too many things being spread out across several services) and instead are coupled excessively to implementation details. That makes development slow and also means I can never be sure that my changes don't break something important.
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].
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.
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?
Name five good things that Hillary has done.
So his ‘downsides’ amount to:
1) you’ll learn more in the first six months than you learned in four years of college
2) you’ll be trusted to contribute to large complex important systems
3) you’ll be measured on your results
4) real ability will help you stand out and succeed
5) you’ll get to collaborate with loads of different people
6) your work will have direct business impact and visibility to senior management
7) you’ll spend most of your time solving hard puzzles
8) you’ll have tons of freedom to define your own path and role and find how to contribute
9) your work will be so compelling your mind will keep working on it after hours
10) the role balances technical and people skills and rewards those who can combine those aspects.
Conclusion
Software development is not a dream job.
Speak for yourself. I’m having a blast.
I think software development “is not a dream job” as people outside think it is.
Most of the time people think you get paid for sitting behind the screen. Which is also true and might be hard for some types of people on its own.
But a lot of people don’t want to be measured on results, don’t want to deal with learning new stuff on the job, having responsibility for something complex that might break at any time quite often for reasons totally not in their control.
I like my software dev job and I also would not switch but I can see how it is not a dream job.
What is the measure for results though? Is your manager competent? Is your team leadership's golden boy or the black sheep?
But a lot of people don’t want to be measured on results, don’t want to deal with learning new stuff on the job, having responsibility for something complex that might break at any time quite often for reasons totally not in their control.
See the blog's paragraph on incompetent colleagues. :D :D
as people outside think it is.
don’t want to deal with learning new stuff on the job
I think this might be the big one. A few years ago I got small window into someone going from no programming experience to getting a job (completely self-directed, not through school or a bootcamp) and he thought he had to learn everything before getting the job. I had to reassure him that no, that's really not how it works in tech - even if you could learn all of ___ right now, there's stuff continually being added so you'll have to keep learning anyway. Basically that typically you'd get the basics down then learn new stuff as you needed it.
His previous experience mostly came from a mix of skilled and unskilled laborer jobs, where even the skilled laborer ones you could learn everything in like 6 months and from there onwards it's just refining skill (as he described it, at least).
Might be an age thing. This is a positive spin, and I agree.
But the stress does eat away at health. It can be fun, but it is not 'comfortable'.
Maybe it is different if you are writing some mission critical code. It can be fun when you are dabbling with web sites, but not so fun if a bug will cause someone to die. So stress levels, and having a blast levels, can very a lot.
And thus the stress levels over time, can cause health problems.
An ‘age thing’?
Curious how old you think I would have to be to have this noncynical perspective.
Like, young enough to still be enjoying things. Sure, I felt the same way for first decade. This is all fun.
But later. Not old enough yet to have done 24x7 support for a few decades, sleepless nights, 80 hour weeks, working on Christmas Morning, to be ground down by angry and demanding users. ( no fault of their own because of their own turnover. ).
Lack of sleep and stress takes a toll on health. So 'age' becomes a factor, because the body gets ground down. Seems like the 'optimistic' takes remind me of just starting out.
But, it is probably more of which industry you are in. Results vary.
eg video games sound like such fun to work on, but every report I've heard of from people who actually work in that industry make me run away screaming that I've never had a programming job in that sector.
You're having a blast because you have a great attitude towards your work and feel empowered. This isn't always true for everyone, particularly if you're in a situation where the organization around you isn't healthy.
I love software engineering too but being a "key contributor" golden handcuffed to an organization that's "optimizing costs" has made me appreciate why some people might not enjoy this line of work.
The thing about ‘jobs’ is they pretty much all involve working for companies.
So ‘dream jobs’ and ‘nightmare jobs’ alike are going to share all the downsides of that: clueless management, misaligned incentives, layoffs, etc.
But my point is, if you’re going to have to work for a company anyway, software engineering isn’t a bad profession to choose.
Additionally, if you decide you would rather work for yourself than put up with corporate life there are few jobs that pivot as easily into starting your own business or becoming a consultant.
You're just furthering my point that your good attitude is a major component of your success. I agree with you 100% and I'm always grateful I get to work in this career, bad parts and all.
For the record, you sound like exactly the kind of person I like working on my teams.
Really good reframing and perspective. I think all this absolutely can be spot on. I have personally experienced this kind of work a few times in my career, and yeah, I agree that when I'm in one of these environments, it's almost certainly a better job than anything else anyone else I know is doing.
But I also think the ability to flip the script into this positive experience really does vary between organizations and even within organizations. And it's basically impossible to evaluate it accurately before taking the job and doing the first three to six months of work there. And then if you do conclude it's not a conducive environment to do great work in, it's easy to feel stuck, or to very reasonably feel like you might just go through the exact same thing at the next organization after putting a bunch of energy into getting unstuck.
I don't really have advice here I guess... I think there's a lot of luck involved.
I guess maybe my advice would be that I think this is one of the good reasons to start out at a "big tech" company if you can. They have all these difference that exist across companies, but they have them across teams or divisions within a single company, and it's both a bit easier to figure out what the good teams are, and a bit easier to switch teams than companies.
Indeed, reading these hard-to-swallow truths actually restored some excitement about being a dev for me!
Love this reframing.
I'm with you but it depends on the company - I was responsible to keep it running for the customers and my boss thought it's better to let me churn out useless work that he can bill instead of fixing the issues or simplify the process (at least internally). I even proposed that he can just bill the same or more hours for the customers for me but I need to automate that shit or I'll go insane. Didn't happen. As soon as I realized that I quit but I burned out pretty badly trying to make it work because I liked the team and the product. Be careful and watch out where you spend your energy and time.
Well said. I think misanthropy and pessimism are endemic with people who spend 14 hours a day talking to computers and don't have healthy social lives or many reasons to touch grass.
I appreciate this positive spin on the list. There is usually a silver lining.
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.
Same here. I have no trouble "closing the laptop", but I can't stop my mind from problem solving. Fortunately for me I don't have any of the "soft" concerns you mention.
The practical side is clear: close the laptop. But on the mental side I do wonder where the right balance is. I've recently started to forget about work at the weekends to the extent that - usually late on a Sunday - I suddenly remember I have to be at work the next day, which is an odd sensation. Probably just getting old(er).
Looks like you just had busy and nice weekends then. I get the same deep reset weekends sometimes, especially when I also take Friday off. Then the next Monday morning I barely remember what to say at the daily stand-up confessional.
That sounds like anxiety. Nothing is so important that it can’t wait for business hours.
And if the company will fail or you would be negatively judged for only working on business hours, there are always other jobs.
Writing down a shower thought that hits you out of your subconscious is one thing, but actively considering work topics off work time is working more for the same pay.
My interactions with colleagues are pleasant enough that I don’t need to worry about them at home. And things like “resource allocation” happens on work time
Or ADHD. That means that I wake up thinking about things - work, house tasks - and I don't get to switch off in the way that you do.
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.
you kidding me. have you heard about 24/7 oncall?
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.
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.
having the app on his personal phone
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).
I find that those who are chronic workers have very little going for them in their personal lives.
Isn't that a truism? If you only work, there is not much time for anything else, I think.
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.
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.
I felt this.
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...
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.
It is extremely easy to disconnect from work.
Clearly that's not the case for everybody. Don't assume that your reality - and what works for you - is universal truth.
I find that those who are chronic workers have very little going for them in their personal lives.
Yeah having kids fixed that for me
After being a software engineer for over 30 year, I agree with all the points. I have come to the conclusion that being a software engineer is one of the hardest jobs. Also because your often confronted with your weaknesses. But that also gives you room to grow. I also have come to realize that being a software engineer, changes how you view the world, because it forces you to think deeper about problems. The problems behind the problems. In sense that alienates you from all those people who do not have to deal with hard problems, are not used to think deeply about problems. And there are a lot of those kind of people in the world, at least a lot that use their voice.
But in the end, I never regret becoming a software engineer, and I also realized that it has profoundly shaped who I have become.
software engineer is one of the hardest jobs.
I chuckled. How can someone write this with a straight face?
If you think it is easy, it is because you have a talent for it and have years of experiance. People who are mental health professionals, teachers, doctors, CEOs, all have what I consider harder jobs, but do you think they would want to switch places and be a software developer 40 hours a week? They would think it is too hard.
There is a medium between "easy" and "hardest job in the world".
People really live in a bubble. Try being a nurse working in cancer kid unit for a few years like my wife. Try being a trucker who sees their kids every other week. Don't you think these people would love seating in their chair from 9 to 5 and make 6 figures?
Maybe I misunderstood what the OP meant by "hardest". I sincerely hope so.
There are just different kinds of "hard". I have lots of nurses in my family who have worked in ERs and ICUs, some of whom nonetheless have told me "I could never do what you do". I think they could! What I do seems way easier to me! But that's not how they see it.
Agreed. Hardest is a high bar. Maybe OP was referring to those roles on a software team: developer, tester, business analyst, PM, client manager, etc.
Yep, everyone I know who isn't already involved in creating software, including a number of people I know who do jobs that I think of as being actually-hard, thinks it seems really hard and magical. Like, not the job aspect of it that we're mostly discussing here, but the "writing the code that makes computers do all this stuff" part, that probably strikes 95% of the people reading this thread as pretty easy at this point. It's just that it's easy to do things you already know how to do.
Don't think it's necessarily wrong though. I can't think of many professions where a large amount of professionals are pretty bad at their jobs.
OP means mentally/intellectually hard, not physically hard.
Of course, it is difficult to compare jobs with respect how hard they are. One could easily argue that every job is hard. Jobs can be demanding in various areas, such as: physical, emotional, psychological, mental and intellectual.
Some thins, I think, make software engineering hard, is because it is not very visible from the outside. Another reason is also that it is different from other forms of engineering, where the product of the engineering is outside the engineering and where it is often easy to add a margin. With software, a very small bug can have big consequences.
I also think that software developement is a very creative profession, while often not viewed as such, where you are often judged on the basis of your creative output. In a sense software developers struggle with similar problems as artists, where there is often not an objective good or bad. Discussions about coding styles are frequently found here on Hacker News.
If only software engineering required or even encouraged thinking, let alone deeply.
Formal systems like computer programming, mathematics or accounting do depend on a certain style of thinking, but I don't think it's especially hard or deep. If something it's shallow and simplistic (which of course has its place).
Formal systems like [...] mathematics [...] do depend on a certain style of thinking, but I don't think it's especially hard or deep.
I'm awaiting your proof on whether P is equal to NP.
And then you switch to security from being a developer and the imposter syndrome hits you in the face like a truck and you'll realize how easy it was being a developer.
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.
I've interfaced with a fair few MDs in the US behind the scenes, so to speak.
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.
Not sure why people are downvoting this - my partner is an MD and uses uptodate literally every few hours, when she's at home - I'm sure it's higher at the hospital/clinic.
Some Doctors are checked out/lazy/make assumptions, just like everyone else.
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.
'd guess that the more academic the education is, the more likely you fall into that pattern.
of treating the most comments stuff and being lost? Would have thought the opposite, no, or am I misunderstanding
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.
I think a lot of engineering jobs have a similar disconnect
Do other careers have such a vast gap between the platonic ideal and the actual lived experience?
Any NGO worker or nonprofit probably has this. Nurses, doctors, and veterinarians also.
Meh. It's not that bad. Legacy codebases can be fun. If you have a good team, your meetings will be meaningful or you will cut them.
I've always liked working in legacy code bases. It's like doing archeology. Seemingly bad code maybe didn't start out as bad code, but was made bad over time because of historical reasons (last minute product changes, time pressure, local changes without understanding the bigger picture). It can be very rewarding to make sense of it. And it makes you realize that any code you write yourself will be legacy code soon too, and someone else will need to be able to make sense of it again.
It depends.
The thing about inheriting an older, undocumented codebase is that it often blows up in ways that you least expect; even drawing assumptions about how a function works based on its name can be problematic.
Or when you remove some "unused" code, only to find out that it was somehow used by reflection and your IDE can't even figure that out because the framework you're using was discontinued in 2010. Also of course, there's no test for that.
Sometimes bad develops wrote bad code, but with a good team, you can do a fun cleanup!
It’s all about the team.
Legacy in business just means it's a real product/process that has customers and/or makes an important output.
Otherwise, if people didn't like it for whatever reason, they could just stop doing it.
It's great to be working on something that's useful and important.
Yeah, a lot of greenfield projects fail, and the road to that failure is fraught with pain and burnout.
Cities are legacy projects, colonies are greenfield. Both have their pros and cons.
Legacy codebases can be fun.
"Legacy codebases" and "fun" should not appear in the same sentence.
Discovering how a large system works can be fun. Even if a codebase is old, but the design is good, it can be gratifying.
College will not prepare you for the job
I'm on the fence. Not initially, sure. But there are embedded lessons that click later.
I was ten years into my career before I needed to write a b-tree or a double ended linked list, but when the need arose I was very grateful for having the ability to recognize it, and the familiarity to act on it.
Some things I learned such as the wonderful value of pure functions just didn't click for about as long. I'd done a ton of Scheme in College and at the time it was nothing but a frustration "Just let me mutate state, this is dumb" it wasn't until I had years of tracking down what the heck was mutating state in a giant old code base that I learned to appreciate functional programming.
Do you need college for that, though? I don't have one and still know how to implement a double-linked list, trees, tries, hash maps and what to test for when implementing binary search[^1]. Just keep your eyes open.
[^1]: https://blog.research.google/2006/06/extra-extra-read-all-ab...
If anything, I miss the linear algebra drills the most.
I was a self taught programmer for close to a decade before going back for a degree and I’ve been working for almost a decade since finishing.
Unlike self teaching, a degree forces you to learn the boring bits as well as the interesting stuff. When I was self taught, I’d flitter around and pick up fun pieces here and there, but with no real focus.
Some people are disciplined enough to teach themselves the equivalent of a 4 year CS degree. Most are not.
And there are people I’ve worked with, without degrees who are far better programmers than I am. But they still tended to have some gaps. I’m fairly certain they’d be even better with a degree.
OTOH you don't need 5 years and $50K debt to learn these basics.
The best college courses taught me more than my jobs ever did. Creating my own iPhone app and reimplementing rowhammer stand out. The app I sold and reimplementing rowhammer required me to learn about C, assembly and CPU architecture fast. It gave me a mindset that still serves me. And sometimes it allows me to pentest my employer because I smell a vulnerability.
The average college course, yea not great…
I can't remember what I did in CS in college. College was fun and there was a ton of interesting stuff in general, but that's just 1 or 2 years worth of learning compared to working full time for a decade or more after that.
Even on the purely theoretical side I think I learned BNF or design patterns on the job. Same for algorithms, you'll see a lot more going through react's inner workings than sitting in CS courses.
It's also very valuable to have a shared frame of reference with colleagues so you can communicate more efficiently. Saying things like "this is like backpressure" instead of having to explain the entire concept is very valuable.
I'm on the fence. Not initially, sure. But there are embedded lessons that click later.
College can give you a great baseline to build upon. I can't tell you the number of developers with 10 years experience and a degree that I've interviewed who could't explain what database normalization was.
Having said that, the vast, vast, vast majority of stuff I know I learned "on the streets."
I 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.
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.
In the Navy if people weren't complaining, we knew something was wrong.
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.
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.
The point about "incompetent people" is a bit harsh. "Competence" is rarely boolean - some people are smarter, some are less smart, but may have other qualities (e.g. being more thorough), some may not be that familiar with a certain technology etc.; that code you have to work on may look the way it looks because it had to be adapted several times to changing requirements without enough time to refactor it properly, not because the person who wrote it was incompetent. There are already enough young developers leaving university full of self-confidence thinking they are God's gift to the job market, so maybe a word or two about giving people the benefit of doubt before classifying them as incompetent is in order. That's not to say there aren't really incompetent people, but you should avoid jumping to conclusions too early...
Maybe, but the people I have worked with have been pretty heavily bimodal, especially by the senior level - many people in the "competent" bucket varied a bit but generally produced workable code (maintainable as well as works now). But there is a distinct class of senior engineer that produces awful code that is hopeless to work with later. Most frustratingly, it does actually work for the current task so those outside the system will only see problems with the later devs to work on it.
But there is a distinct class of senior engineer that produces awful code that is hopeless to work with later
The longer I work on stuff the more I worry this is me. I thought it was the code coming before me, but the code after seems just as error prone.
There's a really easy way to tell.
If I say something like "I've got my sales history in a database and need to graph how many widgets I've sold over time", do you start thinking about concepts and code, or do you start drooling and typing "npm database npm graph npm widget..."?
The hard truth:
Some days, you’ll be the incompetent person.
Or, to put it in the immortal words of U2, some days are better than others (https://genius.com/U2-some-days-are-better-than-others-lyric...)
Meetings are an important part of the software development job.
Imagine the folks building the Linux kernel or other popular, successul, and mission critical software projects sitting in meetings all day long.
I genuinely think that meetings are the only way management can justify their existance and therefore commercial projects consider them as an "important part".
Imagine the folks building the Linux kernel or other popular, successul, and mission critical software projects sitting in meetings all day long
What do you think LKML is? It's a big continuous asynchronous meeting.
"asynchronous meeting" is an oxymoron.
I suppose if we redefine words everything is everything.
> I genuinely think that meetings are the only way management can justify their existance and therefore commercial projects consider them as an "important part". reply
Wait until you join management at some point in your career.
I did. And held few and to the point meetings. I could see how non technical managers were struggling, and that’s how i know that some are simply clueless and serve no purpose within orgs. I managed a somewhat small number of devs - roughly 40, some distributed.
I mostly agree with the points but I hard disagree with point number 3.
Clean code makes the project more easily maintainable. We generally try to keep a standard in code quality (and I would say 98% of the codebase we touch is well written). We also try to schedule refactoring rounds (but that doesn't always happen because of time constraints).
He didn't say clean code was bad, he said nobody cares about your clean code. I assume he meant outside the development department.
That isn't true either though. Sure, they don't care about it as a first order thing, but they care about development not slowly grinding to a halt over time. And writing well structured code is one of the things the software side of the house does in order to do a better job delivering on that desire from the business. If nobody on the technical side has the credibility or trust to make that case, then that's a problem.
Sure, they don't care about it as a first order thing, but they care about development not slowly grinding to a halt over time.
Most only care when it affects them or sales, not when devs are asking to allot time to clean up code or pushing off a release to fix wonky stuff. In my mind that's not caring.
That's like people care that they can't walk up stairs without huffing and puffing, but not enough to actually diet and exercise. That's not actually caring, that's really regret.
I'm fortunate though, my company gives a lot of credence to dev.
In the article:
Don't get me wrong, people will expect you to write good and clean code.
I can agree with this. Clean code is not "celebrated" because it is expected as normal. You won't get a raise for it. You could get problems for not writing clean. But when the business gets into a tight spot, they will accept shitty code that fulfills their desired goal over a nice clean and elegant solution delivered few days later. In this case, the shitty code could get you a raise.
The bullet points in the article are reasonable enough, but almost every explanation is questionable. I’ll just address one.
Soft skills are indeed very important, and sometimes more so than technical skills. However:
Technical skills are the ones you can learn easily. With different projects, you can understand a particular programming language. You can learn its syntax, pros and cons. It's just a matter of practice.
Technical skills are not just about programming language syntax. I wonder how long the author’s been in the industry (apparently “a lot of years”) or how narrow his role is, that he’s never had to learn completely new concepts or paradigms.
And even the soft skills section is bizarre. What can I learn about utilizing my soft skills from the author’s list of all the times they thought a colleague was unhelpful or “toxic”?
Weird article.
I’d say OP has 5-7 years. Because if you have both soft and technical skills together you stop writing code after about your first decade and start solving much larger problems.
This is bad advice in many organizations. The best architects I've ever worked with were excellent coders and kept up to date with everything even if only 10% of their role involved writing actual code.
It's very hard to be a technical leader without credibility.
I wonder how long the author’s been in the industry (apparently “a lot of years”)
8y, most likely including internship. His resume is on the blog. I wondered as well and checked.
Indeed, I see a big difference between developers in my team based on their general reasoning and discrete math skills. How capable are they of abstractly interpreting code in their head? Are they used to thinking about how to prove something is correct? Are they used to thinking in terms of graphs? That sort of thing. Those are technical skills that seem pretty difficult to learn.
11. Perception is reality. Ideas mean nothing if you can't sell them. Providing actual value to the company means nothing if you can't sell it. You will work with people who cause more damage to the company than they bring benefit but are good at selling it. It does not matter what you think about what you are doing, it only matters what other people think. If you can be good technically and be a good communicator, the world is your oyster.
12. Most developers are very wrong about what would bring value to their managers. If you think you are underappreciated for your good work, there might be potentially very simple things that you could change that you aren't aware that could make you much more successful. Your manager might care less about how elegant your solution is but might remember you were two days late with it because he had to explain to his boss why the entire feature got delayed. Every situation is different and there is nobody on your team to help you -- you are responsible for reading the situation and making what is important.
--
And regarding:
10) You will profit more from good soft skills than from good technical skills
I would add more. You will profit more from learning an orthogonal skill or field. You can be good developer by just being able to gather requirements and implement them. But you can be extremely valuable, sought after specialist if you know how to do those things AND ALSO know some other field not commonly considered by developers.
In regards to 12, there is a really good article out there somewhere about doing what makes your manager happy, not doing what he asks you to do.
Oh, agreed on that. I would say doing what your manager needs rather than what he/she asks you to do is a senior-level trick. You need to be experienced to be able to pull it off successfully.
Absolutely. Become and expert in something, and then make software to solve problems in that domain. That's how you get rich.
You will almost certainly experience a layoff in your first few years of post-college work. You may or may not be affected directly by the layoff, but either way your first layoff experience makes an impact on you. You will watch others around you who may have even been great at their jobs lose their jobs for no fault of their own. It sucks.
When a layoff happens to/around you, TALK ABOUT IT WITH YOUR PEERS! Every one of your peers will be having feelings. Engineers are not good at talking about feelings. But OMFG seriously, when that first layoff happens just drop everything you're doing, grab a pile of people you work with and go out for a long lunch right away and then talk about wtf just happened. It makes the situation less bad and will help you get back to being productive much quicker. Your boss won't mind, and if they do, they're a horrible person.
- First job: laid off. Found a new position in 2 weeks. - Second job: wanted to move, so this doesn't count - Third job: laid off. But I was already looking for new jobs, it just worked out really well for me
For the ones I got laid off - severance pay is always a nice bonus, particularly if you can get a job prior to it running out. Just remember that when a layoff happens, it's can be more beneficial than a loss (both in monetarily and shaking up things a bit to find new stuff to do.)
You will almost certainly experience a layoff in your first few years of post-college work.
Or you'll get hired on the cheap right after the layoff, and everyone left behind will hate your fucking guts for it. Especially when you need their help.
if they do, they're a horrible person
Very bad gamble if you need the job and a bunch of people just got laid off. If you can afford to move jobs, you would have done it already after the layoff.
"Nobody gives a f** about your clean code"
Absolutely false. And you'll know this as soon as you need to change or maintain your own code.
Even if you're a purely cynical person who does not care about your team members, or the future developers (and you're just optimising for business outcomes) you have the incentive to save yourself a lot of pain, as well as embarrassment when customers ask you for something and you need to say no.
I would, at minimum, rephrase that point to "Do clean code for you (and for your colleagues), not for some abstract virtue of writing clean code"
Looking at the paragraph that follows that headline, they are already making similar points.
A less charitable interpretation is that "Nobody gives a f* about your clean code, because if you're dealing with code, you're a nobody in the business"
You do not create clean code for others, you create it for your future self. And he/she will appreciate it.
True. But you should also write it for your fellow developers/engineers. If the culture among engineers in your job discounts the value of clean code, you're probably entering a world of pain.
Sure, you should not obsess over clean code, as it does not directly produce value. You should also not expect your manager to understand its value. But if your fellow engineers frown upon efforts to improve code quality, start looking for your next job. The mental drain is just not worth it.
Esentially, where the clean code is appreciated, mediocre engineers/developers will eventualy acquire "guru" status, just because they happened to be hired a year or two earlier than the better ones. And will often be unfriendly to anyone "threatening" their status.
Future maintainers, who could be you. It has happened to me a few times, and I thanked my past self every time.
It doesn't even have to be clean code. Sometimes I'll even settle for understandable code. In my experience, however, few people care about this. My most common comment in code review is "add doc" or "add explanation"
The user doesn't know how the codebase looks. The user just sees what features that product is offering. So don't get overly attached to your clean and elegant code. Focus on shipping the feature on time and bug-free.
This is a slippery slope. True, the user doesn't see the code. But they do see the feature set (or lack thereof), and the speed at which you're able to update that feature set to suit your customers is a function of how easy the code is to change. In turn, that ease of changeability is a function of how easy it is to read, maintain, and reason about.
Focusing on "shipping the feature on time and bug-free" is good, but at the extreme it can lead to the mentality of "I'll fix the tech debt later", with "later" being indeterminate. Which is when the old saw about tech debt being like credit card debt starts to bite one in the ass.
I love the idea of shipping a "bug-free" feature before the heat death of the Universe, it's beautiful to have noble ideals like this.
I take issue with #3. The clean code is for you. Future you. You will be substantially more productive if your code is clean. You will end up being the "rockstar" (groan) because you can implement 2, 3, 5, 10(!) times faster on your clean code than your peers. I am living proof of this. And then when your managers and company realize you're the cash cow you can ask for absurd raises and get them. You are going to be hard pressed to do this with crappy code bases.
Not just future-you, future-everyone-on-the-team.
And in my experience it isn't true that nobody in leadership appreciates this. I think it's easy to make the case that it is worth investing today to make it less burdensome for a team in the future, which may or may not contain the current team members, to evolve the software being written in the moment. This makes sense to everyone in a business, because the same is true of any business process.
"Clean code" is not the only way to accomplish this; processes and documentation are other things you can do. But I also think it's easy to make the case that writing comprehensible code actually has the best lifetime return on investment. It isn't hard to do - indeed, it's often easier to ship working features with well-structured code, and it requires less future toil than documenting a process that requires working around poorly structured code.
But of course often times there is a tipping point where further tinkering with making code "clean" is no longer net positive. But I think codenames that tend toward I dunno, maybe 95% cleanliness provide good value to an organization.
I couldn't agree more with this list. While I was at university,I used to imagine software engineering job like a place where like minded people talked all the time about algorithms,new technologies etc. A place where senior engineers would guide/mentor you, where you could take time to create the best code/solutions... :D For me, discovering that soft skills often are more valuable than tech skills was a huge wake up call.
Well it is kinda like that, if you have a software engineering job at a university lab haha. But even there there's usually heavy politics.
There are a lot of formulas on how to do estimates, and everyone has their own rules. I also have my own rules.
The actual way to produce estimates can be found in the excellent book Thinking Fast and Slow by Daniel Kahneman: you have to consider a previous project (or, better, several of them) of roughly similar in size and scope, and use that as an anchor for this estimate. You're allowed to add or remove a bit because of a slight difference in complexity. But the golden rule is never to say that this other project doesn't count because, although it seemed similar at the start, it encountered unexpected problems. That's the whole point!
If you haven't worked on a project that large (or kept good enough notes about how long it took), well, tough luck, you can't produce an estimate, any more than someone who doesn't know any software dev at all can.
Looking back at a project with this in mind I was surprised to find the distribution of subtasks (into 3 big buckets of "main complex logic", "simple GUI", "reports/presentations") was roughly equal rather than about 80% on the first one as I suspected. There's no way a rule like "add 40%" can help you with something like that.
The book discusses a great example where they were preparing a university syllabus to teach various biases, including the underestimate bias and this very technique to avoid it, and they still underestimated how long it would take to prepare the course (even after being given information about how long previous courses took to prepare!).
Another recommendation in the same vein is How To Measure Anything by Douglas Hubbard. And Superforecasting by Tetlock. Estimation/forecasting (same thing different emphasis) is a problem we know quite a lot about, and we know how to train people to issue calibrated estimations.
The first step to learning anything is figuring out how to get feedback on your performance. For estimation, probabilistic estimations are the way: https://two-wrongs.com/verifiable-software-development-estim...
In the words of Terry Pratchett, "It’s indoor work with no heavy lifting". And it pays astonishingly well. Which are useful things to remember when it sucks a bit.
A mentor once told me, "If you get frustrated, just go to the bathroom. When you are done, remind yourself you just got paid $10 to take a poo."
Overall, I think this article is good.
I've been in the game a long time and there is not much here I would disagree with.
"Working in software engineering often means long working hours. Most of the time, you are glued to a computer screen, with little work-life balance."
For sure this is true. The younger you are, the easier it is to deal with and be amazingly productive. As you get older, life creeps back in and you get a bit of balance.
When you get to my age it becomes less about screentime and more about problem solving. Something I am very happy about.
As a career, it's 8 out of 10.
Eh that's one of the least universal ones in there. I've worked in tech for a decade now across 6 positions in 4 companies and I have never had any complaints about WLB. If anything, I frequently feel like I'm getting away with something when it comes to how little I can actually get by with doing if I want to.
I don't consider any of these to be 'facts'--I'll save you the click (unless you're curious):
TL;DR
1) College will not prepare you for the job
2) You will rarely get greenfield projects
3) Nobody gives a f*** about your clean code
4) You will sometimes work with incompetent people
5) Get used to being in meetings for hours
6) They will ask you for estimates a lot of times
7) Bugs will be your arch-enemy for life
8) Uncertainty will be your toxic friend
9) It will be almost impossible to disconnect from your job
10) You will profit more from good soft skills than from good technical skills
Conclusion: Software development is not a dream job.Honestly sounds like the author has only worked at toxic places. I can't relate to half his points.
Software development certainly is a dream job for me.
I would also add:
- stay humble. you are inherently no better than the guy who cleans the floors, even if you are paid more
- your benefits package may rise very rapidly but it will hit a plateau unless you begin caring deeply about a domain other than mere software. You will need to start getting serious about something like finance, healthcare, automotive, etc
- stay humble. you are inherently no better than the guy who cleans the floors, even if you are paid more
The guy that cleans the floors is doing a useful job, and doing a better job of it than I could do.
The other programmers on the other hand...
I have been doing software professionally for nearly 25 years.
Even if the points the author lays out are very true, don't you ever take them in as being true for you.
One thing I have learned in all these years is that you can rule your own narrative in your job. And when patient, factual and not backing down when demanding answers on 'why', you will find out fast if you are made for being part of an often labour heavy workforce.
Fact is that what the authors lays out, is not at all special to software engineering jobs. All industries are like that. We are not special in any way. And it starts by telling yourself that you are not special, but that you differ yourself by having a qualitative integrity - though that will take many years to get and always be in process.
Fact is that what the authors lays out, is not at all special to software engineering jobs. All industries are like that. We are not special in any way. And it starts by telling yourself that you are not special, but that you differ yourself by having a qualitative integrity - though that will take many years to get and always be in process.
Aye, a lot of the OP points sound like any white collar job.
I've supported OT roles in Aviation and Railroads, and this sounds more or less like any engineering role I've seen.
It's not a bad job if you have what it takes, but the reason we're paid a lot of money is that many couldn't force themselves to do it even if they wanted to.
There's a lot of responsibility, uncertainty and frustration. Very often we're doing something that no one did exactly the same way before, which means there are no clear answers and no one to delegate responsibility to.
Maybe not so much in a junior position; but the more senior you get, the more of that you'll have to deal with.
I agree about soft skills, learning to communicate well and deal with other people is a big part of it. Half the job is really more about diplomacy than technology.
It's not a bad job if you have what it takes, but the reason we're paid a lot of money is that many couldn't force themselves to do it even if they wanted to.
You make it sound like we toil away every day, almost as if we were breaking rocks or hammering iron. We don't. We have cushy and sedentary jobs that many could do and even more would die to have. Most LOB software development is not special and not that complicated. We don't create unique works of art in every project we work on, although the occasional piece of code does tickle the brain.
There are many software developers working on much more complex things (compilers, OSs, high-performance computing, firmware, rockets, etc) but those are in the minority. And I firmly believe that anyone with enough training and experience can write OS code, or compiler code, or firmware, etc.
There's a lot of responsibility, uncertainty and frustration.
I'm not going to say there isn't because there's certainly a lot of that, but it's a small price to pay for how good we have it. We also, as an industry, don't deal with more or less BS than other white-collar, office jobs.
I recently had a conversation with a friend going through her (medical) residence: 12+ hour shifts several days in a row, combining hospital work with lectures. Nurses have it even worse. We (software developers) should be very grateful.
I skimmed the bullets and pretty much agree with all of them. I’ve been doing software dev for 25 years or so so have been around the block a few times. There’s a lot of good to go with the bad though, sometimes you meet incredible people who you just stand in awe of and other times you get to have a huge impact on someone and get to watch them blossom into something great.
But yeah, the most painful is you rarely get a greenfield project, most of the time you’re bolting on features to a shotgun shack of a codebase and praying for the best.
sometimes you meet incredible people who you just stand in awe of and other times you get to have a huge impact on someone and get to watch them blossom into something great.
i can verify this was my experience at my last startup!
There’s some good points on here that I might share with some tutoring students, esp about greenfield and how that’s really a coveted thing in a social setting of engineers. I do think the tone should be worked on so it is less.. bleak. Like, I don’t really remember being nervous about how long something would take me, unless I was concerned it was impossible to do to begin with. I also didn’t have to deal with thinking about the job all the time, because I was doing it, which is a tongue and cheek way of saying if you want to succeed, work life balance might look different to you than to the peer next to you.
The greenfield thing is always funny to me - I really struggle with greenfield projects :) I don't like being faced with a blank page.
The rate at which this stuff happens is proportional to the average age of employees at the company
This is exactly what I noticed as well.
Some truth but this seriously lacks nuance. Not all colleges or companies are equal.
I put quiet hours on my mobile phone for my business emails
I just don’t install the email profile on my phone
My job can send me a second phone just like they send me a second computer, so I can turn that off too
3) Nobody gives a f** about your clean code
#3 should be that your definition of "clean code" is almost certainly wrong.
Great list. Ten years in, I have to say I completely disagree with #6 though. My 2c, never give estimates. They are a trap.
As a developer, if you give an estimate, it will be questioned, second guessed, and then negotiated down to 1/3rd of its former self. Then when you do the work, it always takes twice as long as your original estimate. The whole dance of estimation only succeeds to indoctrinate developers into the political environment of the organization, it turns developers into mini-managers over their own time and perturbs their productivity.
Software engineering as a discipline has to move away from developer estimates. If you’re articulating the work that needs to be done, estimating the work, then doing the work, the only function of your boss is to report on your execution. The demand for developer estimates are a consequence of managers trying to turn themselves into highly paid messengers with no skin in the game. I’ve seen what that does to developers: late hours and weekend work, horrible diet, stress, weight gain, divorces, it’s ugly stuff. Don’t let it happen to you.
Have your boss make the estimates. They have access to resources you do not have. They can look at past performance on similar projects, they can look at actuals. That’s their job. They need to do it.
If they ask you for an estimate, “how long would it take to do x?” never start by saying “it would take about …”. Ask a question, something like “what do you mean by x?” Or “have you considered y, is that something we should be concerned about?” etc. keep doing that until you’ve gotten your boss to the edge of their knowledge. How they react will be telling. You end up providing more value in the long run because instead of giving your leadership a false sense of security, you’ll be educating them about execution risk and setting your projects up for success by setting up future conversations to be constructive. If you do fall behind, you have ammunition to fall back on in meetings “last month I asked about x, because I was concerned, and now that concern has come up.”
I generally find I write perfect clean code in my own personal projects, however at work my colleagues keep complaining about it ;)
Sometimes you don't know the whole story. I have seen some cases where a person just can't do their job properly. They are burdened with tons of tasks and doing work for 2 people.
Never mind people who are just starting out -- I think many people on HN could really benefit from this perspective.
This is what makes co-op programs so great! They solve problem 1, allowing you to encounter these truths over time in the real world before you graduate.
It's just an empty protocol to prove their purpose of existence in the company.
Sounds like he came from a pretty bad development environment. I am sad to think this is what he communicated to young developers.
These meetings can help to surface problems, provide a shared space to refine work as a team, create a plan against available resources... All of this helps developers move faster and ship more frequently.
#10 should be near the top. hugely important
The points in this article match what's in the book "Poems for Software Developers". https://www.amazon.com/dp/B0CMNR4G39 Like the article says, you'll probably not get a greenfield projects, you are going to spend a lot of times in meetings, and you aren't going to just be left alone to code. You will have to work with people on a team. Knowing the technical aspects of programming is one challenge, but another challenge is coordinating the effort of developers to drive to a goal, on time, and according to requirements. That coordination effort is a lot of what the experience working as a software developer is all about.
I think a lot of this is good advice even for people outside of software engineering.
Nobody gives a f* about your clean code
There is more nuance to this. Soft engs need to realize what stage of product and business lifecycle they are working on. Most importantly, get into the mindset individual contributor not just a programmer [1] (highly recommend reading Patricks blog on this)
1. If you're building 0 -> 1, the focus is shipping early and faster. This is not the time to crib about SLOs and chaos testing. I'm not saying these things are not important, but very likely they are way down the list.
2. Once you have crossed the chasm and have a mature product or platform that product engineers rely on. Then reliability, fault tolerance SLOs etc matter a lot more. This is the phase, I'm more concerned about using the right abstractions and ensure tech debt is managed well.
3. Product is in KTLO mode - In this phase, you could probably spend quarters LARPing on making things better and afford to work on things that very likely have diminishing returns.
Nobody gives an eff about your clean code, if no customers are using it.
[1] https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
While many points are true (but IMO not all) I would not see all of them in a negative light. Especially for a new grad just starting in the field.
For example, yes, you will likely work with existing codebases, but in most other professions you will work within established constraints, not all of which are fun, etc.
On the flip side, a good knowledge of software engineering offers excellent money and opens a lot of doors. Want to live and work in Europe for a few years? Take 3 months (unpaid) off to surf and recharge? Negotiate remote options? A good software engineer is likely to manage those with some negotiation and planning. Not many other professions would allow that today. My 2c.
RE estimates it’s not about the time selected, it’s about managing expectations. People need to know what they can expect from others in order to collaborate, the skill is in knowing when and how to communicate in the framework you’re working in, so that everyone you’re working with has reasonable expectations. You can get it wrong plenty so long as you manage people’s expectations well.
This is distorted thinking at best:
"This may be a shock for some new folks, but it makes perfect sense. As a software engineer, your primary task is to generate value for users. Writing code is just a step that accomplishes that goal."
No other engineering discipline thinks this way. An aviation engineer's primary concerns are that the thing they're building is (1) safe and (2) efficient. Whether or not that product is profitable will depend on marketing and competition at a whole other level. It's NOT the engineer's primary concern. This is also true for electrical, chemical, civil, etc. engineering.
If there are a lot of software engineers that think this way, all that means is that the discipline is still in its infancy and hasn't adopted the kind of engineering standards that others have had to over time. Maybe the kinds of standards and regulations applied to sellers of electrical devices should be applied to every company that sells software?
There's one source of bugs that the author doesn't mention: time, and how our understanding shifts with it.
Sometimes the understanding of what a business object (or one of its attributes) represents sometimes shifts, over the course of several years. Sometimes, that shift is suble and easy to miss, like that it used to represent a desired state, and now more often represents an observed state.
Sometimes, other ways to manage some objects come about, and of the original use cases of an object or table, only some (formerly niche) use case remains.
Sometimes our use of language drifts, for example when a third-party tool is introduced that uses similar but not-quite-identical vocabulary.
All of these can lead to formerly correct behavior now being obviously wrong. Sometimes it's hard to remember the context of the original implementation, and you ask yourself why anybody in their right mind would have done what you did back then.
so true.
This stuff could roughly apply to any job
I dodged all of this hard by taking an interview with a smaller engineering-adjacent company. A lot of these points seem like the reality when working at a gigantic conglomerate that doesn't take its software arm very seriously. Mine does because the software analysis is the core product.
1) All of my previous practice and my Master's-level statistics and signals processing prepared me well for this job.
2) Out of the gate, my boss gave me free reign to greenfield replace a lot of old tools.
3) My clean code and the documentation around it is needed, because obfuscated and undocumented code is what previously shot this company in the foot, and is what I was replacing.
4) Everyone in the software part of the company is competent; the only issues come from outside our department.
5) We have one one-hour weekly meeting to talk progress and potentially connect on important points. Everything else we discuss as needed.
6) Estimates are rarely needed because I made the right choice of languages and tools. I can make changes or add features same-day or within a couple days. One longer-term project I'm on has no deadline; it's needed, but not urgently.
7) My choice of language and tools makes bugs easy to track down. Most of my issues are solving for engineering edge cases.
8) Not that I'm always certain, but uncertainty is never really an issue here.
9) I hard disconnect from my job, and my boss wants it that way. Nobody has my email or phone number. When I go home, I go home.
10) I've had soft skills my whole life, so I've never run into that issue.
I didn't get the fabled six-figure starting salaries people everywhere seem to be chasing, but I've concluded those aren't truly real and were driven by $2 trillion money-printing valuations.
If anyone is curious about my tools, I use Nim to analyze signal data and output analysis and reports; it's a CLI tool that puts out standardized data formats, which can be invoked by server scripts whenever needed. Most of our systems have already been overhauled to use it as the crux of our data analysis. I replaced a lot of old deliberately obfuscated C and PHP.
Alleged Agile purists and Scrum Masters with a MEDIUMTEXT worth of Alliance certifications in their email signature who prattle endlessly about SWAGs, cone of uncertainty, “it’s _just_ an estimation”, tee shirt sizes, etc. will corner you with a demand to give the number of days it will take to do x with no necessary details or requirements, make you play planning poker with some other equally bewildered chump, ignore that and write whatever number they already had in their head into the roadmap which will be several months short of your guestimation, and then chastise you and your team for not delivering what they wanted even sooner than that, and before you’re even done they start “knowledge transfer” and “switching to maintenance mode” so they can whisk you off to another equally fucked project; get ready for it.
It’s one big partially dysfunctional cargo cult where your toughest career problems are less frequently technical but political, interpersonal, and organizational.
I think I’m one of those professors that actually do try to stay (somewhat) up to date with what the industry is doing. Sadly, the SE industry in my area (mostly consulting companies) isn’t keeping up to date, so they complain why we don’t teach our students C#.
3) People and businesses usually won’t value your “clean code”.
4) You will often work with incompetent people. Especially in larger organizations.
Pretty well agree with everything else.
In addition, a huge amount of the time you spend will be trying to figure out what the code is actually supposed to do.
Pretty good piece. All new devs should be lucky if they find an org that is exempt from even 1 or 2 of these problems.
Sounds very nice. Nobody talks, that highly paid jobs attract all levels of psychopaths. And nobody teaches to work with or under them. Then you go into psychogames asking if I am insane or something wrong with this workplace. If you’re lucky - you leave early and healthy. If not - end in some fancy mental health clinic.
Already mentioned layoffs. My older colleagues went through these too. But really only when the company was going bankrupt. We have now lifestyle layoff rounds to prepare companies for future challenges. Some dude in completely healthy and profitable company decides to throw away 5% or 7%. Job security is gone. At the end you’re a row in payroll’s excel.
As in every job, you will sometimes have incompetent people in your environment. Working with them is very frustrating. They waste so much time and create a toxic environment. On top of that, they are extremely unproductive.
That is not even the worst case. There are incompetent people out there that look like they are productive.
An example: once we had to implement a bridge to an API to some piece of software from some third party vendor that one of our customers used. This started with authentication. Of course they didn't use OAuth or anything like it but their homegrown bastardised version: you authenticate with a username + password - nope, not a refresh token - and it hands you a temporary token that you then use to hit the API until it expires.
Of course it didn't hand you expiration time so you'd have to do requests until they failed, at which point you did the login dance to get a new temporary token.
Of course it didn't fail with a 403 or any other status code or in-band information you could use: everything failed with a 500 and an empty body. But that's not even the worst part.
Of course there was no HTTPS, so everything went in clear over the interwebs. Not to fret, they thought of that: they implemented encryption. Oh, before you ask no they did not use a Authentication header or anything remotely like it, for the login phase they had us pass username+password on a GET request query string, with values encrypted.
Of course they did not use anything cryptographically reasonable that you could find off the shelf, instead choosing to shoot themselves in the foot with using the OpenSSL API to come up with their own thing. So they picked the worst possible thing ever, ECB - If you have no idea how bad ECB is, click the following link and let it sink for a moment that you're looking at the ciphertext.
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...
Of course they provided documentation with three code examples (C#, Java, PHP) so as to implement it. Of course each one of these four had gaps covered by the others, yet the overlaps had none of these four things agreeing.
Of course the code for the statically typed languages did not even pass the compiler.
Of course the code examples were ostensibly copy pasted from StackOverflow, and then further butchered (with localised names).
Of course the actual server implementation was a fifth thing that disagreed with the four above. So the easiest way was to "simply" MITM their official Flash client and brute-force-reverse-engineer the payloads, tuning OpenSSL arguments until your code produced the same output as what you intercepted. In a twist of irony, this being ECB helped.
And no they did not use anything like public+private keys, DH, or even a PSK, however fancily implemented. See, values were encrypted for every payload, but how do you make the API server understand your first request ever: the login? Of course you would not send the username and password in the clear over the web! So it has to be encrypted! So you encrypt it and stuff it as a value in the query string! But now how does the server which has no idea what the key is can decrypt it? Easy! Base64 the key and pass it as a second query parameter! Now auth is encrypted and the server can decrypt it! To hell with "PS" in "PSK", that's for losers!
Of course, somewhere, someone got accolades for having implemented that API in record time complete with full documentation and examples, ready for folks like us to peruse.
Of course we had to vigorously defend ourselves for being comparatively unproductive in front of two CEOs (including ours), a CTO, a contractor, and an employee that implementing a client to this API is taking us more than an afternoon, and that, glossing over the details about the fitness of ECB, it was a stupendously pointless loss of everyone's time when the API vendor required us to pass the key in cleartext alongside the encrypted payload, a fact that probably still eludes all of them to this day.
Mobile development back in 2010-2014 is just full of greenfield projects and I am just so lucky to be part of it. Every month it feels like someone has a great idea of an app.
There were no reviews back then in Play Store (formerly named Android Market), same with iOS, app store does not yet had a very strict review.
The majority of them are forced by a person who is organizing them because that's the only "work" that that person is doing.
This a pretty cynical and unproductive way to think of meetings, management, and the essential task of coordinating people's efforts.
Isn't it also your responsibility, increasing with seniority, to make sure that the team's time is used well?
Most problems today stem from scale? A big org of with 100% non technical people and 100% technical people where the sweet spot was the small game studio from 25 years ago, nerds, but social, tightly knit, experts but generalists because of size, close to each other, and pretty small.
no one cares about providing value to users. We could create value without making profits. People care about profits nothing else.
So, no I think your sole purpose as an employee is to make other people rich, as in any other profession.
But there are worse fates in life than writing code for money.
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 :)
Are these hard to swallow? It feels like the author is pushing a particular tone when stating facts (with maybe a couple debatable points) that any software engineer would agree with.
I was lucky to figure this out before it was too late. I was studying for CS masters and worked as a software developer for ten or so years from quite a young age and started noticing I hate most of it, and it was just getting worse.
I love programming, but vast majority of software development isn't programming even if you work as a "programmer". It's a constant bureaucatic fight with piles of horrible codebases and technologies and bad ideas (that aren't even yours).
I switched to academia and now I actually get paid to program. Not ridiculously like most white collars, but still unreasonably. And I don't have to turn into a badly fitting mindless cog for the prime hours of my life.
I always refer to this paper when I think about advising graduates: https://blog.pragmaticengineer.com/software-engineering-sala...
There are different problems in different orgs with different value adds. You can be super busy firefighting for a company that doesn't value your work or calm, well-paid but unchallenged in another.
Also the same general pattern of learn -> earn -> own applies in tech. Learn your trade, milk it for a number of years to setup your life, own your own consultancy/company.
I pause Slack notifications after working hours. I disable them on weekends.
"I go home at the end of the day" -2010
This is a pretty good article and I suspect a lot of it applies to almost any job. Replace software engineering with accounting or electrical engineering or whatever and it's probably all still true. Working with other people can be difficult, soft skills and kindness are what make it less difficult. Find places where the culture is a good fit for you and where the interviews focus heavily on behavior.
Also, work on yourself. There's a lot of toxic attitude in this post and even more so in these comments. Stones and glas houses come to mind.
You don't have to be apathetic in response to the realization that politics is a major thing at higher levels in bigger organizations or that estimates will almost always be wrong. That's like not enjoying sunny days because eventually there will be bad weather. Very silly.
I've been a SWE for about 10 years.
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.
software development is not a dream job
If your worst complaints are that you have to work with others, that solving the problem matters more than how you do it, and you have to sometimes have a pointless meeting, I don’t think any job will work for you. High wages, good conditions, medium social status, high bargaining power, and you get to do something you love. It is the best job available.
I disagree about the clean code. It’s what defines engineering vs ‘mere development’.
Spending time on design up front and doing the smallest thing that could possibly work allowed you to move very quickly later.
THAT gets noticed by management, and if you preach it long enough they buy in.
Clean code is nothing more than just making sure a code base is fully consistent in its structure, self similar, or crystalline in its structure. Basically no cowboys or egos allowed: everyone writes things in the same manner and style, so everyone can understand it. It takes a lot of maturity from devs to do this and a lot of code reviews.
I first saw this coding technique on a medical codebase that tested drug interactions, and later on a very much ununamed defense code base.
Whatever the standards are ends up being s bit arbitrary, the actual value is ‘everyone does one thing’.
I have another (more fun) way to say almost the same thing as OP: https://eddiots.com/
In TFA, author uses a swimming analogy and it's alright but for me I find martial arts is the most relatable analogy and so many of Bruce Lee's thoughts are applicable...
A lot of what you will learn in a degree is like doing your katas. They're fun to learn but many (if any) of the moves are too situational and abstract that you'll rarely get the chance to apply them. And when you do, you may forget about them in the moment under pressure.
But learning those techniques in a safe environment you'll have a chance to develop some finesse and also have good technical foundations. But there's no replacement for actually getting field experience by sparring/fighting.
A seasoned brawler/street fighter will seem uncouth and may have some unorthodox habits but they will be more successful in the day to day than most theoreticians who aren't out there applying what they're learning.
Some Bruce Lee quotes I like wrt software engineering...
Adapt what is useful, reject what is useless, and add what is specifically your own.
If you spend too much time thinking about a thing, you’ll never get it done.
Before I learned the art, a punch was just a punch, and a kick, just a kick. After I learned the art, a punch was no longer a punch, a kick, no longer a kick. Now that I understand the art, a punch is just a punch and a kick is just a kick
Mostly agree, but i think the more seniority you get in your company the less you will deal with these issues and of course changing jobs helps. So basically you might encounter all of these but not necessarily.
And starting from scratch and college is basically the same point
Hard-to-swallow truths?
I thought that's just common knowledge.
I don't think the learning how to swim analogy is good. Where I live it's mandatory for children aged 5 and above to take swimming lessons and to test out at some point. So, there's a lot of involvement with this subject.
Anyways. Theoretical part helps. Doesn't guarantee that you learn how to swim, but is a necessary component for you to learn well. College CS education is just outright harmful. Not only does it not give you practical knowledge, a lot of what is being taught is outright wrong. If we stretch the allegory of swimming lessons, it would be like if in these lessons, while only teaching the theory, the instructor told you that breathing underwater is possible, if you try hard enough, or that diving and landing flat on your belly is the way to dive.
Another aspect that I find really upsetting about college CS education is that it focuses on inconsequential, transient issues, at the same time completely ignoring important ones, and, at the same time, not investing any effort into trying to systematize knowledge. There's very little effort (or non whatsoever) put into building advanced concepts from first principles. Often times links necessary to connect several concepts are missing and the students aren't even told that these concepts are somehow related, or even if they are, then there's "magic" in derivation which is never explained. A typical example would be how in automata theory the course usually ends with building some very simple programs using Turing machine, and the closest next link in understanding programming languages is learning some modern elaborate programming language like C or Python.
College CS education is way overdue for a fundamental revision, and I wish CS had its own Bourbaki...
College will not prepare you for the job
no, it will not, it has a completely different role, the other name "University" gives you a very strong hint about it: what you learn in university is a universal way of thinking, of acquiring knowledge. The dirty secret is it doesn't matter at all whether you learn this by studying human anatomy or the stars blinking above. By the time you leave aside from very basic stuff your specific knowledge will be outdated anyways for multiple reasons. And your assignments are irrelevant to any job you will take, the primary criteria for your teacher when choosing assignments is the ability to grade you fairly and easily on a task with a known complexity.
And there's no fast way to do this. We do not know how. There are a few, extremely few people who seem to be born with a mind honed to this but most people are not Terence Tao :D and actually need the five years of university to get there.
Its good to share your experience with new comers, I agree with some of it, there's a lot of stuff that's debatable, and I struggle to present my own experience as "truth" to begin with.
As someone who spent a lot of years in this industry
Amazon calls qualifiers like "a lot" "weasel words", because they hide the information into a subjective expression. I had to go to the authors resume to understand what's "a lot" and it seems that it's 8 years. That's certainly more than average when you consider that the number of devs double every 5y, but I don't consider that "a lot". I have more than double that, and I still don't call that "a lot". I still have massive realization about work every now and then, which prevents me to establish "truths" given that it's all just perception. Side note: I tend to disconnect a little as soon as someone starts a sentence with "as a X", because they're trying to use their qualifiers as proof of what they say.
College will not prepare you for the job
I feel like my own college prepared me well.
The majority of software engineers hate meetings. But remember that your job is also to communicate about things openly and proactively.
I hate most meetings because they're useless. Half of the meetings I go to exist because a) someone does not like reading so they want me to read the status I gave in an email b) cargo cult c) because its more convenient for a single person to waste everyone else's. It's great that we can have meetings, some are productive, but in a software company that ships software, protecting the time of people who actually write the software seems like a good idea.
Nobody gives a f** about your clean code
In the companies you went to, maybe. I give a f** about clean code, because once in a while I am gonna get called at night because stuff's broken, and I don't want that to be because of your shitty code. (also, I rarely saw a college graduate produce clean code, it seems to be something that you need to have experience to do).
You will profit more from good soft skills than from good technical skills
There's truth in there, it's important to develop your communication and presentation skills. To be fair a lot of my graduate year at college was around that so, once again, I felt prepared. Saying that you will benefit more from that than tech skills is against a stretch that will vary based on where you are at on both sides, and generally speaking it pays more to be good at what you are being paid for.
It will be almost impossible to disconnect from your job
Strong disagree, and I don't think that this is a message you should transmit. Funnily I think I pivoted my point of view on that topic around the experience level of the author. I think it's a tendency of your early years, when career is your priority, to always prioritize career. Later, when you find other things you enjoy, disconnection from work is entirely possible. Don't take your computer when you leave for vacation. Be strict about not communicating after hours. Dont reply to your phone (I don't even have work emails on my phone). If you really love your job and spending more time in it is your hobby, go for it. If that's not the case, learn to disconnect.
This reads like a person who has walked past a couple of turns in the road from the starting point, and is looking back to describe the totality of a grand journey to the his naive uninitiated inferiors.
Kid, you're just at the beginning.
The last point is the most important one, last of course, as our industry does not respect communications, despite it being the main cause of all our irrational management deadline issues.
You will rarely get greenfield projects
If only I had known that one earlier. I was fortunate enough to work only on greenfield projects for my first fifteen years as a software engineer. However, at some point, I was brought into a brownfield project [1] for maintenance, support, and bug fixes.
The difficult part was not related to things like clean code, architecture, and so on, but to the lack of consistent thought processes around the choices made, as well as the fact that there is a lot of tacit knowledge in people's heads that aren't documented, and how arbitrary convoluted things can be, especially if foliks wants to ensure their own employability through manufactured complexity.
It took me at least three years to realize that new technology is the exception rather than the rule.
[1] - Brownfield project it's something that has something green still but starts to be muddy and swampy.
I had 20 years in industry from tiny startups to megacorps, W2 and contractor. Now I'm an instructor at a state university. So I've seen all sides. :)
Re point 1, you'll learn a lot in the first few months in your job. The old adage that you'll learn more in the first 6 months on the job than you did in all of college has been around at least since I graduated nearly 30 years ago, and almost surely existed for decades before that.
But you can't spend four years learning to learn and have zero impact from that. If you got through college and the only thing you have to show for it is a diploma, you didn't do it right.
The author is correct that it's not everything you need. But it's only four years and it's tough to prepare a student for every single possible work environment on the planet. The only real option is a foundation, and they pick up the rest using their learning skills when they hit real life.
Also, re "So don't get overly attached to your clean and elegant code. Focus on shipping the feature on time and bug-free." There's an interplay between all these concepts that I don't think the author acknowledges.
#2 and #3 are a bit at odds with each other. I certainly get tired of coming back to the same problematic code that's difficult to read and maintain. I appreciate others (and myself) for writing clean code.
This actually describes the job pretty well in my opinion, as someone who has been in this field for over a decade now. Not everybody is cut out to be a software engineer, and the "day in the life of" youtube videos where they never do any work and just eat all day of free food and socialize just paint an inaccurate picture of reality, making the job seem a lot more glamorous and easy than it is.
The thing that struck me was that the points would ring true for virtually any profession. Yet most young people migrate the transition into the working world OK, and even thrive.
The one unique thing about coding might be the intractable problem of estimation.
The user doesn't know how the codebase looks
Technically true. But the user knows when code is in a poor state. A poor C codebase in a security critical area users will find out about. It will crash, need critically patching all the time etc.
If a game engine has a messy code base (Say, they have two slightly different renderering subsystems which makes things clumsy) then people will notice because the games will be late, buggy, cancelled whatever.
For most users though it's that the software is slow, costly, buggy, doesn't get new features quickly and so on. And you can't really tell the reason why. But users DO notice it. Managers certainly notice it. Any manager should recognize a situation where you spend 80% of your time on bugs/regressions, while new features get less time, and take much longer than aticipated to implement. And any manager should instantly recognize that this is invariably due to a poor-looking codebase. Not poor communication, not (other than indirectly) because of bad developers, not poor tools, not anything else. Just messy code.
I think the point with regards to clean code is somewhat changing. As companies and their clients adopt process certifications such as ISAE, static code analysis reporting is slowly becoming a requirement for the release process, driving measured code quality improvement and directly tying it to business outcomes. I feel like some other points are also less severe in technology oriented companies focused on cloud native, continuous delivery and that manage based on the DORA metrics.
I think college prepared me for some of those things.
Group projects were a standard thing throughout most of my time there and they introduce you to the messiness of teamwork.
I still recall one semester during which I was in two group projects with another guy and we negotiated who'll be slacking off and who pulling their weight in each of them so that everyone passes.
One friend of mine is still holding a grudge against a mutual friend of ours who was extending the deadlines given to him to deliver his part until it was too late.
I got top marks in a project where two guys just took over seeing that me and the forth guy were incompetent.
I took one for the team when our lecturer said that he won't be giving top marks to everyone, so we need to decide who loses 20% of their points - I volunteered because I knew he personally disliked my choice of technology (NodeJS - we had complete freedom in that project with regards to platform/language) and I just needed to pass.
Overall a learning experience.
9 - I’ve been doing this so long and this gets harder and harder. I’m at the point I’m so severely burned out I’m planning early retirement to get out of this industry all together. For me what makes it even more worse is I didn’t get into this field until I was in my 30s. Beforehand I drove a forklift in a warehouse, I was in the military, then an electrician, and finally a electronics repair tech afterwards. Those fields the disconnect was passive, didn’t even have to think about it. Software you have to jump through mental hoops to remove yourself and that’s just as exhausting as the job itself. I dream of a job working at a garden center or maybe driving a forklift again. This field sucks.
Hmm, Been in software development for 13 years not and I don't really agree with most of these.
Maybe it's common, but I'd say certainly not a guarantee.
These kind of essays are needlessly negative.
In terms of being relatively accessible, well paid, safe, interesting work software engineering is probably one of the best jobs ever in the history of humanity.
Yes there are downsides, but IMO they are relatively minor and pretty similar to what people in any other field experience - incompetence from coworkers, office politics, too much time talking and not doing, and the concern for the bottom line of some ideal of perfection or craftsmanship. In addition, for most jobs that require college, what you learn in college is only the foundation and you will need to learn a lot on the job (see for example residency for doctors, flight hours for pilots, clerking for lawyers, etc)
In exchange, you get a relatively well paid job that only requires a 4 year degree (if that) to land an entry level job. There is a vast opportunity for increase in pay either through experience or starting your own company. In addition, if you want to start your own company, it is one of the easiest fields with much smaller regulatory and capital requirements compared to almost anything else.
It is not just well-paid work, it is interesting work. Lots of people, including me, find software engineering fun and fulfilling. There is just something amazing about creating something cool. Many of us like this so much, we have non-work side programming projects of our own.
Software engineering also offers some of the best work-life balance potential of almost any high paying field.
And again, compared to other high paying professions, it is much easier to get into. Although people complain about interviews, they are less stressful than trying to get into medical school or law school and there are a lot more entry level programming jobs than medical school and law school headcount. It is also much more accessible than anything in entertainment or media.
So in summary, like everything else in life, it is not perfect. However, currently, it is one of the best, most accessible careers, possibly in the history of human civilization.
OP needs to change companies.
1. Most academic institutions were never intended to subsidize corporate training costs. While this line sometimes gets blurred these days, one must assume you are learning basic skills 80k other people already have.
2. The primary HR issues I’ve seen is a lack of humility, inexperience, and people entering the field for the wrong reasons. Financial motivations are fine and all... but giving a toss about what you do is important in the long term. There is zero correlation between degree level and productivity… Indeed, some kids get by on social media with an army of Googling friends to try and game through challenges (think of a Borg-cube that assimilated a planet of smug morons.)
3. Some people are cultists, and firmly believe success is bestowed on the truly deserving. In some ways they are partially right for a cog-in-a-machine proprietary process position. However, the range of skills needed grow exponentially as the organization shrinks, and rapidly deprecates people not willing to show any initiative.
4. Your work is likely naive garbage at first, and while management doesn’t know any better... your peers do. Expect to be hazed until one can contribute coherent work. Yes, you will be working on projects that match your skill-set, and if you don’t clue in your career will be a short one.
5. Assume you are the dumbest person in the room, and be pleasantly surprised when you are wrong. Some folks have literally met 80k people just like you, and whatever cleverness you think is original... is often just tedium in another perspective.
6. Your loyalty will not be rewarded. The industry will not suddenly develop integrity, but it is rather a personal boundary you choose after seeing peers exploited.
Good luck. =)
Without knowing the exact expectations of the people the author spoke to, I'd imagine lots of the misconceptions are on-point.
One personal exception for me was how university (not college) prepared me for my future in software engineering. The courses I took quite often involved group projects of 2-3 people completing work cooperatively. Undoubtedly this was - by far - one of the best and closest to real-work experiences I had during my earlier education.
Compromise, discussion, division of labor, and a healthy bit of experience with individuals who'd prefer to be part of the project credits but ideally do as little of the work as possible.
You have to put in extra work while you are in college. Code more projects besides homework and seminars. Do some volunteering. Learn about business domains to prepare for the job that awaits you.
lol yeah, or you do not do this and just get paid to learn all this shit on the job.
Not to mention you might have to work on projects that are mostly divorced from programming entirely, like making plugins work together in WordPress.
These aren't hard to swallow at all - how about this:
Good requirements do not exist - Writing good requirements is months of work -you have to interview business stake holders, ask challanging questions, you ahve to involve industry experts and have developers think, not code.
Its safe to say this almost never happens.
Agile is an insidious ruse - its popular because it frees management from having to commit to planning and discovering requirements. However management still expects engineers to provide them outputs of waterfall - accurate estimates, architecture, etc.
CV driven Architecture is common
Engineers have a complexity addiction and feel inadequate and impotent if they are 'just building' something simple.
So simple projects get bloated to inckude Kafka, kubernetes or some other buzzword of the year. Instead of discussing business problems and missing requirements, engineers prefer to discuss technical complexity. So they often commit to adding technical complexity before they've understood business complexity.
Then when they hit business conolexity, they have no mental capscity or bandwidth left to address it
Communication between business and Eng is usually broken
To arrive at good design decisions, one person needs to have great understanding of business and technology. In most projects, this person does not exist. Design is riddled with qeustions like 'Do we really need to have feature X, it doubles complexity but only 5% of users would even care". To even understand that, business needs to communicate commercial information to developers, or developers have to educate business. This rarely happens, and so these decisions are usually not even identified
Well, I liked they used MonkeyUser comics. I feel those guys "get it." Sort of like a more tech-relevant Dilbert (without the racist screeds).
I was a software engineer for a long time, and a "first line" manager, for a long time.
Most of the points are correct, but some did not apply, in my company.
For one thing, I worked for a Japanese corporation, and clean code was a really big deal to them. I had a project canceled, once; partly because the code wasn't up to snuff.
If you work for a Japanese company, get used to meetings. They absolutely love meetings. Especially in-person meetings (rack up those frequent flyer miles!).
That said, I really enjoyed the job. It taught me to write Quality code (which means absolutely nothing, for most tech companies), and they treated me and my team with respect. That's not something that you'll get, in most modern tech companies, and it meant a lot to us all.
Approachability and emotional intelligence have been two of my greatest weapons in IT, not my technical skills. Humans are and always will be creatures of emotion, not logic. It sounds corny but I usually strive to be the guy people would enjoy having a beer with.
Reads like a chatgpt article. Nothing new or insightful or hard to swallow.
I'd just like to comment on these points on a 30 year perspective...
Point 4 - incompetent people. They are great. When they fuck up, which they do often, you can save the day by simply being average. Just make sure people know that you saved it.
Point 5 - meetings are great if remote. You can sit there muted on a zoom call for hours tweaking with your bike or playing games on your other computer.
Point 6 - estimates are always wrong so don't put too much effort into it. What people value is how long you spend making up lies so spend some time on it!
Point 8 - Uncertainty. Let other people handle that and hang themselves with it. That's what software architects are for. Be there to clean up the mess afterwards or at least complain about it.
Point 9 - Eventually you do become able to disconnect from your job. One day the fucks just run out. Embrace that early on and save yourself a lot of stress.
Point 10 - The only soft skill is politics. Any sufficiently large organisation employs many politicians. The best way to deal with politicians is analyse the factions and stay neutral. No one can drag you to their side then.
There is a missing point though: objective one is getting paid. Anything else is secondary. If they stopped paying you how much of a shit would you give about all the other concerns? There you go now you understand. Nothing matters so don't get too wrapped up in it or upset about it.