I've always liked working in legacy code bases. It's like doing archeology. Seemingly bad code maybe didn't start out as bad code, but was made bad over time because of historical reasons (last minute product changes, time pressure, local changes without understanding the bigger picture). It can be very rewarding to make sense of it. And it makes you realize that any code you write yourself will be legacy code soon too, and someone else will need to be able to make sense of it again.
The thing about inheriting an older, undocumented codebase is that it often blows up in ways that you least expect; even drawing assumptions about how a function works based on its name can be problematic.
Or when you remove some "unused" code, only to find out that it was somehow used by reflection and your IDE can't even figure that out because the framework you're using was discontinued in 2010. Also of course, there's no test for that.
I've worked on plenty of legacy code over 37 years. It all depends on the management environment and how bad the code is. Sometimes legacy code is like being mired in quicksand.
I've grown to appreciate legacy code more than greenfield. It's real code that makes money (hopefully) and solves problems. Code is bad? Well, it's probably for good reason as real-world problems are messy. Also a lot less analysis by paralysis.
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've been in the game a long time and there is not much here I would disagree with.
"Working in software engineering often means long working hours. Most of the time, you are glued to a computer screen, with little work-life balance."
For sure this is true. The younger you are, the easier it is to deal with and be amazingly productive.
As you get older, life creeps back in and you get a bit of balance.
When you get to my age it becomes less about screentime and more about problem solving. Something I am very happy about.
Eh that's one of the least universal ones in there. I've worked in tech for a decade now across 6 positions in 4 companies and I have never had any complaints about WLB. If anything, I frequently feel like I'm getting away with something when it comes to how little I can actually get by with doing if I want to.
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.
It's also very valuable to have a shared frame of reference with colleagues so you can communicate more efficiently. Saying things like "this is like backpressure" instead of having to explain the entire concept is very valuable.
I'm not degreed, been working with and for PhD's, people with and without degrees for 3 decades including several stints at valley startups and never heard anyone use the term backpressure outside of a mechanical engineering context.
Do you need college for that, though? I don't have one and still know how to implement a double-linked list, trees, tries, hash maps and what to test for when implementing binary search[^1]. Just keep your eyes open.
I was a self taught programmer for close to a decade before going back for a degree and I’ve been working for almost a decade since finishing.
Unlike self teaching, a degree forces you to learn the boring bits as well as the interesting stuff. When I was self taught, I’d flitter around and pick up fun pieces here and there, but with no real focus.
Some people are disciplined enough to teach themselves the equivalent of a 4 year CS degree. Most are not.
And there are people I’ve worked with, without degrees who are far better programmers than I am. But they still tended to have some gaps. I’m fairly certain they’d be even better with a degree.
>I'm on the fence. Not initially, sure. But there are embedded lessons that click later.
College can give you a great baseline to build upon. I can't tell you the number of developers with 10 years experience and a degree that I've interviewed who could't explain what database normalization was.
Having said that, the vast, vast, vast majority of stuff I know I learned "on the streets."
I can't remember what I did in CS in college. College was fun and there was a ton of interesting stuff in general, but that's just 1 or 2 years worth of learning compared to working full time for a decade or more after that.
Even on the purely theoretical side I think I learned BNF or design patterns on the job. Same for algorithms, you'll see a lot more going through react's inner workings than sitting in CS courses.
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.
Future maintainers, who could be you. It has happened to me a few times, and I thanked my past self every time.
It doesn't even have to be clean code. Sometimes I'll even settle for understandable code. In my experience, however, few people care about this. My most common comment in code review is "add doc" or "add explanation"
True. But you should also write it for your fellow developers/engineers. If the culture among engineers in your job discounts the value of clean code, you're probably entering a world of pain.
Sure, you should not obsess over clean code, as it does not directly produce value. You should also not expect your manager to understand its value. But if your fellow engineers frown upon efforts to improve code quality, start looking for your next job. The mental drain is just not worth it.
Esentially, where the clean code is appreciated, mediocre engineers/developers will eventualy acquire "guru" status, just because they happened to be hired a year or two earlier than the better ones. And will often be unfriendly to anyone "threatening" their status.
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.
After being a software engineer for over 30 year, I agree with all the points. I have come to the conclusion that being a software engineer is one of the hardest jobs. Also because your often confronted with your weaknesses. But that also gives you room to grow. I also have come to realize that being a software engineer, changes how you view the world, because it forces you to think deeper about problems. The problems behind the problems. In sense that alienates you from all those people who do not have to deal with hard problems, are not used to think deeply about problems. And there are a lot of those kind of people in the world, at least a lot that use their voice.
But in the end, I never regret becoming a software engineer, and I also realized that it has profoundly shaped who I have become.
And then you switch to security from being a developer and the imposter syndrome hits you in the face like a truck and you'll realize how easy it was being a developer.
If 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.
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.
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).
Why? At least I'm not waiting for mathematicians to e.g. negotiate peace in middle-east, produce a room temperature superconductor or raise a well functioning triplet.
(Obviously me doing those is even more unlikely than me doing P=?NP, but I'm not sure how I'm involved here.)
Don't you see the issue with claiming that "mathematics is shallow and simplistic", but then not being able to follow up on that claim by actually solving one of the most famous open mathematical problems?
If it were shallow and simplistic, any moderately intelligent person would be able to do it - yet decades of world-class mathematicians have failed to produce a proof.
I did not mean shallow and simplistic in a way that any moderately intelligent person would be able to do it. Also all (most) mathematics is not P=?NP level stuff.
Especially being simplistic (unambiguous, mechanistic) is a feature for what mathematics is used for.
> Also all (most) mathematics is not P=?NP level stuff.
The list of open mathematical problems is as varied as it is vast. But even going beyond that, it's clearly evident (e.g. by considering drop-out rates of technical degrees) that most people seem to be having a really hard time even with comparatively elementary mathematics.
> Especially being simplistic (unambiguous, mechanistic) is a feature for what mathematics is used for.
I'll give you "unambiguous" up to a point (there's still enough debate about which axioms are the "correct" ones, though). But "mechanistic" is plainly wrong. The set of true theorems (e.g. of ZFC) is famously undecidable, so there can be no algorithm that can capture all of mathematics.
All you are saying is that you have been been working on trivial software systems and haven't been exposed to anything particularly large scale or complex so far in your career.
Also you must be confusing basic arithmetic (1+1=2) with mathematics in general.
Go read some papers on deep learning architectures or learn about the Fourier Transform then come back and tell us how shallow and simple it is.
Mathematics requires the most sophisticated and deep thinking that the human species is capable of. Very few humans have the raw intellectual capacity required for being a productive mathematician.
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.
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.
Very bad gamble if you need the job and a bunch of people just got laid off. If you can afford to move jobs, you would have done it already after the layoff.
My first internship in college, on my last week, my entire organization got laid off. We all went out to lunch at 9am, none of the engineers went back to the office that day. My first job after college, I was there for 6 years, we had I think, 11 layoffs in organizations I worked in, the first one was less than 6 months after I joined. My 3rd job after college, I was there for 5 years, we had at least 3 different layoffs.
In all cases the managers were completely understanding about the mental impact of the layoffs, both for those directly affected and those who kept their jobs and would need to pick up the work of the departing. Never once did I see a manager expect any work to be done the rest of that day after a layoff was announced.
If you ever work for a manager who isn't compassionate during a layoff, I'm sorry, that sucks.
> You will almost certainly experience a layoff in your first few years of post-college work.
Or you'll get hired on the cheap right after the layoff, and everyone left behind will hate your fucking guts for it. Especially when you need their help.
- First job: laid off. Found a new position in 2 weeks.
- Second job: wanted to move, so this doesn't count
- Third job: laid off. But I was already looking for new jobs, it just worked out really well for me
For the ones I got laid off - severance pay is always a nice bonus, particularly if you can get a job prior to it running out. Just remember that when a layoff happens, it's can be more beneficial than a loss (both in monetarily and shaking up things a bit to find new stuff to do.)
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.
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
> 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.
If you are getting paid as an engineer, let that happen. Don't ignore ideas just because it's off hours. You don't have to let that thinking take over your life: make a note of the new idea and get to it monday if you want. But these solutions are precious. When they happen, they happen.
That section of the article unfortunately conflates two types of not switching off.
* Late at night, quick check of my email or Slack and maybe even reply (either to get it out of the way or to show off how hard I'm working).
* While I'm in the shower, thinking about some interesting logical problem (can be something mundane like how to clearly express something in a report).
What is healthy and what isn't is subjective. But most would agree the first is not healthy, while some would say that the second is OK. Personally, I think it's fine (nice even) and certainly doesn't interfer with social or family life.
You (comment I'm replying to) have added a third which is quite different: "chronic workers" are those that are flat out working for extended hours. That's not really the same as not being able to switch off.
I don’t take any job where I would have to wake up from sleep to handle something. Some jobs have stated on-call, but the consequence of not handling a 3am call is nothing. In which case you make more money/hour by not responding to night requests.
The products I’ve worked on in my career largely operate on US business hours, so this has never been a real issue for me.
If I were receiving calls about work more than once a year, I’d quit.
lucky you. SWE job elsewhere in the world (or maybe if you are on H1B in USA) implies 24/7 oncall duties. or you and your family get deported where you come from.
and you can't just quit. you quit, your visa immediately reworked, as tied to your employer. and again. deportation.
Couldn't agree more. Worked with a guy and he would respond on slack almost immediately-he was addicted to work and having the app on his personal phone. he had nothing else going on in his life.
Personally, if I shut my laptop there is no way to contact me for work related issues nor should there be.
That’s hideous. If you are going to carry it around everywhere anyway at least use your work phone for everything. That way you get at least some of the upside (work pays for it).
> It is extremely easy to disconnect from work. Turn off your laptop and live your life.
The problem is not that I can’t stop work. I can sit around for a week and nobody would notice. It happens.
But when I do work, I care. I want it to be nice, beautiful and make everyone’s lives easier. And I want that now. I cannot just flip those switches off when I go home (or am home, when doing wfh). It would probably be objectively better if I rested my mind a bit, but my work happens in big bursts.
It is, and yet I suspect many chronic workers can’t recognize it as one.
It is obvious from a Birds Eye view, but those stuck in the toil rarely understand that they are losing their chance to build a meaningful life apart from work.
Considering that the author of TFA assumed (wrongly) that his inability to disconnect from work is a universal problem, I don't think it's fair to criticize the comments here for just following his example.
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 told a guy I mentor this once. You can make a career out of only knowing the right people and you can make a career out of only knowing the right things. The situation you want to be in though is knowing the right people AND knowing the right things. That’s where the real money is.
Eventually my team lead asked me what was going on (he probably had gotten complaints about me breaking the tests).
I told him what I had done (which is easy to show in a git show commit_id) and I guess he responded to them saying that we would not revert the change.
In general I prefer to not have in person discussions for conflicts, so that there is a trail left behind, and I can take hours to respond, so I don't get heated up.
To be fair, the best team leads I have had were all far from the strongest developers on the team.
The best team leads job isn't to dev, it's to represent the teams interests to the larger organization, and I have known some people who have really gone to bat for us, while at the same time barely being able to code genuinely getting angry at CI for pointing out obvious problems with their code.
Dude I don’t know. Representing the team means understanding and making sure the architectural approach and interfaces/contracts with other teams are solid and will stand the test of time. This is certainly different from leetcode skills, but I’ve never seen a truly bad coder have any success at it.
If by team lead you mean manager, sure. If by team lead you mean tech lead, absolutely not. They should be one of the strongest developers on your team.
> 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.
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.
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.
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.
> The only skill you need to get promoted is to laugh at the jokes of your boss and schedule meetings to demo your n-th rewrite of the same thing.
You can't choose your colleagues, but you can choose your company. Some of them have fair evaluation processes and try hard to avoid biases. Same thing for meetings, not all companies/teams have long meetings.
> I'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.
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.
> 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!
I agree with you, and it's very simple to define such a level: use as much discipline as you need to ensure shipping features at an acceptable rate in the long term.
Too much polishing lowers your release rate. Too little discipline will hurt the "in the long term" part.
Thats a good way to put it. Shipping value rather than features though. Which is represented as long term shareholder value, but within some kind of ethics (don’t fuck the customer type stuff).
Thinking in terms of value could mean you sometimes suggest weird things like removing features, cancelling WIP (sunk costs) etc. when appropriate. Or spending way more time polishing than seems necessary or conversely getting something out that looks way too quick and dirty. There are cases where no tests are OK despite what I said but usually MVP stage stuff where no market fit exists yet.
Have you experienced just speed. Or speed at any cost? I.e. releasing really buggy features that customers complain about and churn on? Obviously with enough VC and marketing dollars anything could be possible.
> 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.
Shipping broken, especially code that looks ok but it secretly broken - is far worse than having no code at all. Once it's in place, it gets dug in like a tick, and if it's a pile of poor assumptions and wrong logic, you're in a much worse spot than you were with a clean slate.
If everyone else is spending all their time cleaning up the broken shit he built but won't fix, and he continues to produce more broken shit faster than everyone else can keep up with fixing it, he is a 10X programmer. Not because he's actually 10X better, mind you - he just makes everyone else 10X slower.
4.1.00175-update3: Never buy version x.1 from a company that never ships version x.0 of anything.
This kind of company is often run by people who think "People don't buy x.0 because they're afraid of bugs, so always ship x.1 as though we fixed the bugs." while failing to actually do the QA to earn that version bump.
Which predictably results in customers refusing the company's x.1 because, in their own words, "I'm not going to pay to be their beta tester.".
He gets promoted = double click cv.doc and get updating for me. Team leading is about people but fuck you need some level of competence. Infact I say you need more technical skill in some ways to be across everything. How will this TL have
high standards if he short circuits his unit tests and then fiercely argues for it?
With Haskell, if it compiles then it works. But not for the reason people think. If you spent the time learning Haskell, you probably are smart, conscientious and thought quite hard about your program.
That said type obsessed people invent things like property based tests (basically fuzzers for math people). They test the shit out of their code!
> How long does it take you to go to the store? Yes you might die in the process and take ∞ time, but one normally considers common inconveniences in this. A senior who can't estimate isn't a senior.
A senior who can't navigate the politics around estimating is missing key skills. But they still can't estimate. To estimate something you have to know what you are building and the steps to take to build it in advance. Senior engineers usually don't have enough political weight to stop that changing half way through a project and therefore cannot provide estimates. They can estimate hypothetical scenarios that are unlikely to happen.
I 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.
There's a three-pronged approach when dealing with it:
- Pad.
- Communicate risks.
- Communicate assumptions.
Then when assumptions are wrong, immediately communicate that this will change the estimate. When risks hit, communicate that a risk hit, and whether or not you can absorb the impact in the planning. If not, communicate the expected delay. Pad that too.
Communicate, communicate, pad, and communicate.
(Padding, BTW, may feel dishonest, but it isn't. It is making the assumption that a certain share of you risks will strike and making allowances for that.)
If you still get in trouble for missing estimates, pad more and communicate in writing. Then when people start blaming, you can point to the emails sent. To their/your boss if necessary.
> (Padding, BTW, may feel dishonest, but it isn't. It is making the assumption that a certain share of you risks will strike and making allowances for that.)
This. It helps to realize that when someone asks "how long will X take". What they are actually asking is "When can I rely on X being done by?". If you say 2 days and it takes one, no problem. But if you say one and it takes 2, they've already told the client it'll be done tomorrow, arranged for the machinery to be in place, and now everything is jammed up based on your delay.
Estimating is as much art as science and requires understanding the context around the estimate and how it will be used.
also offer alternatives, preferably at the same time you communicate the risk. When the risk hits you can then start making recommendations about the workarounds you've already communicated.
This stuff is fluid but too many technical people feel as if it's not.
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.
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.
Even on the store point: I might notice I’m low on fuel and fill up on the way. Easily turns a 15-minute errand into 20 minutes. Estimations in the context of a software project are similar to a promise that my trip to the store will only be 15 minutes which I’m held to even if I notice the low fuel gauge.
Shopping list is set and I should be in and out in 15 mins but it turns out there is no ketchup - so do I go to another store to get ketchup or mustard will do. Product owner my Girlfriend has to decide because she is doing the cooking and will present it to customers our guests, and she knows if they like mustard or not because she talks to them more often than I do.
But yeah going to another store might make dinner late and I cannot know this until I actually arrive at the store that there is no ketchup on the shelves.
Its a good metaphor also because if you have an appointment in 20min you would never go to the shop 15min before. Yet managers will force you still out and to the shop because of your time estimate.
Part of estimating is accounting for those contingencies. Given above, depending on my audience the above estimate will be either 30 minutes, or 15 minutes but could be as long as 30 depending on these factors. Part of estimating is accounting for the setbacks one can (reasonably) expect to see, to give the other party a timeframe within which they can be (reasonably) certain it will be done.
Of course there could be a fire on-route causing a jam that turns your 15 minute trip into 2 hours, but that's sufficiently unlikely it's probably not worth building into your estimate (but could be depending on the stakes involved! If someone is going to die you should probably factor this in so we can plan for that contingency). In that instance instead you need to communicate when it happens so that everyone involved can recalibrate.
Yeah, I had a PM who taught me to do this by doing it themself. My estimates are actually just doubled from how much I expect it to take when I know the design and can work with no distractions.
I’ve also worked with managers who “negotiate” as others sometimes describe. Of these I see good and bad. One who was aware of short- and long-term goals of our team and asked for estimates so they could decide what features we need to include; another who already promised the features and the deadline and is asking me to tell them that they did not overpromise despite my observations. (“I don’t believe I’ll be able to deliver those features by that date.”)
Others in between, including some who don’t like being told explicitly that I double the estimate. Worse still, the one who halves it as if to correct for some mistake.
I guess the moral is that developers aren’t the only critical party when it comes to communicating estimates. Managers do their own job; good, bad, or otherwise.
-------
> depending on my audience
Other than some managers I assume another developer or a good technical manager, and it’s a good approach. Sounds at least similar to explicitly stating that you doubled your “no distractions” estimate. Too bad it seems that an unfortunate lot of people work with the bad “negotiating” type who might even be so disrespectful as to correct their co-worker’s mistaken opinion -- which they asked for!
(Not to leave this as advice for the parent commenter. Just wrote some thoughts and figure I can share for anyone who might get value from them.)
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).
One of the things that makes me so successful is that I always try and have a backup plan. "our goal is X, if we fail to meet that with approach Y then we'll use approach Z. Lets prepare for approach Z while we're also preparing for approach Y and evaluate and switch to approach Z as early as we possibly can. We still want approach Y so we'll continue working on it even if we start using approach Z to successfully launch".
The issue is that there's a fluidity in that thinking that many many MANY technical people either don't have or don't employ.
In my experience writing out assumptions together with estimates tends to improve estimate accuracy a lot, by challenging the assumptions (and estimates) more at estimation time, and making it more visible when changes occur at implementation time that impact estimates.
As for negotiating estimates down, it is up to technical leadership to refuse to do that. Not easy, but doable.
One of the most productive teams I worked on spent time at the end of an iteration to look back on our previous estimates and re-estimate them. We got much better at estimating the remaining work we had, and knowing whether we would hit deadlines or not.
My favorite is being asked to estimate a bug fix before I've had any chance to analyze the issue.
It's like calling a mechanic over the phone and asking how much it will take to fix your car. The mechanic doesn't know if the engine just fell out of your Model T or if you're just trying to put the key in backwards. How about you bring it in first, then we'll look it over and go from there?
Sometimes you can ask some questions and get to, "Well it's probably X which would take Y but we'll need to see". Then they get Y stuck in their head and it turns out to be the one time out of twenty when the cause isn't actually X but something much more involved.
If you're being asked to estimate a task without insufficient information on what the task is, punt it back with 'More information needed, we'll look at it 3 weeks from now in the next sprint planning'.
Accurate estimates are impossible, but you can get better at them. Getting better at them mostly entails increasing your estimate to the point that it feels absurd, and then doubling it. To become a true expert, double it again. Another approach is to always bump it up a unit of time. So an hour becomes a day, a day a week, a week a month, a month a quarter, etc.
Really, you just have to be a pessimist. Instead of saying what people want to hear (it's simple and can be implemented quickly), you need to imagine the long-tail worst-case scenario where everything that can possibly go wrong goes wrong, then give that number. If people don't give you a somewhat incredulous look when you give an estimate, you probably were too optimistic. Just remind them that you're imagining a worst-case scenario and say that you hope to have it done sooner, but don't back down on your estimate.
Another thing to realize: at the business level, deadlines are often picked arbitrarily to create urgency. The specific date of the deadline is usually less important than just having some deadline, any deadline, to motivate everyone. Business people will pretend the deadline is Very Important, but it's all an act, more or less (arguably it's a necessary one). Remember this when giving your estimates.
disagree, not all tasks can be estimated accurately depending on circumstances but this does not imply that it's impossible to estimate any task accurately.
No matter what the task is, things can go wrong that you didn’t anticipate.
Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before. Better make some coffee…
Some version of this can always happen, and as a task gets larger, it is almost guaranteed to happen multiple times in multiple variations. Since you don’t know what problems will arise, there is no way to know how long it will take you to fix them. You can stay up all night in order to pretend that your “quick and easy” estimate was accurate, but that only takes you so far.
yeah, and maybe I'll have a heart attack and die while going to take a piss but that doesn't imply it's impossible to accurately estimate that it's going to take 5 minutes for said piss.
What if, while cooking dinner, a meteor crashes in my kitchen and so my estimate of 30 minutes to cook dinner turns out to be incorrect? That _obviously_ means the conclusion is that it's impossible to accurately estimate how long it takes to cook that dish so we should never do so.
There has to be a name for the type of reply your post represents.
you mean the same world where no one has heart attacks and meteors have never hit houses?
Both have been documented to have happened, yet somehow you didn't seem to think that should be taken into account when considering estimates for cooking and pissing.
If your shit is breaking so often you're afraid to give an estimate, that's a you problem.
And yes, we had an internal team that w/i the last 6 months couldn't go a week without a deployment problem. Ask me why they no longer have that issue.
Software has an unusually fat long tail, to an even worse extent than real engineering. The probability of something unexpected popping up and inflating the time something takes by an order of magnitude is much, much higher than the likelihood of the same happening while cooking.
This ends up coupled with the fact that practitioners (of anything productive) tend to think in terms of 50-ish percentile estimates (i.e., there's a 50% chance this project is done in this amount of time), whereas business people care about 90th-99th percentile estimates. In software, the difference between between a 50th percentile estimate and 90th percentile estimate can be more than an order of magnitude in time spent.
I'm going to repeat what I said to another poster.
If your shit is breaking so often it's affecting your willingness to estimate, that's a you problem.
I'm driving to another state for the thanksgiving holidays, and I have an estimate for how long that will take. Is it possible when I walk out to my car that the battery died the night before? sure. Am I going to factor such an unlikely event into my estimate? no. Does that imply it's impossible for me to accurately estimate how long that trip is going to take? No it doesn't.
Only in software could someone be using a tool that constantly doesn't work and they never consider replacing it or fixing it. Imagine if a carpenter showed up to your house with a hammer whose handle fell off once or twice an hour but they expected you to pay them for the loss of productivity rather than purchasing a hammer whose handle doesn't fall off.
Not quite sure how you found your way onto a tech forum without any understanding of what software development entails, but unlike carpentry, where every time you want a new wall the carpenter needs to go through the same process to make the wall, or in cooking, where every time I want a roasted turkey the cook needs to cook a turkey, software almost never does the same thing twice. If you find yourself doing the same thing twice, that's a tool problem.
That produces a much fatter tail distribution, because you're doing someone that no one has ever done before, and thus no one knows exactly how long it's going to take.
odd, because my experience is that your CI/CD pipeline does the exact same thing repeatedly.
Perhaps the answer to your confusion about my experience is that I don't suffer tools that hamper my productivity.
Put it another way.
I ran a raiding guild for several years and about halfway through that stint I recruited a player that raised the bar for what I thought was possible. Perhaps you need your bar raised.
> Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before.
[Managers] are like children. They want everything right now, and they want it their way. But the secret is to give them only what they need, not what they want. — Montgomery Scott
> I've been to the store before. A lot. I've never hooked in new library X to the codebase and implemented that new functionality.
Which is why you'll get better at estimating as you get more years of experience under your belt, and why estimating is something that seniors are better at than juniors.
Even after 20 years you may never have hooked in new library X, but I'd be willing to bet you've done something kind-of similar, and your estimate will be more accurate than a person with 1 year of experience and has never done anything remotely similar.
> Estimating things you've done a lot is trivial, and pointless.
Keep in mind you are not providing the estimate for the person who has done the task many times, you're providing the estimate to people who have never done it before. So for them, it absolutely is not trivial.
> 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)
>And he could find the same amount of deficiencies in your own code.
I'm amazed how many people in this thread seem to believe that it's literally impossible for one dev to be less competent than another, let alone by a significant margin. John Carmack is objectively a better developer than me, and by a huge amount, but I don't feel ashamed or like a lesser person because of it.
Thing is, I don't search at all. I just find them because they stand in the way of me doing whatever it is that I'm supposed to be doing instead of debugging his code.
Also, when people find a bug in my code (which does happen, naturally) I don't spend weeks trying to gaslight them into thinking there really is no bug. I just fix it :)
> The only skill you need to get promoted is to laugh at the jokes of your boss and schedule meetings to demo your n-th rewrite of the same thing.
As far as what the system actually tells you your job is: it's not to do good work, it's to be perceived as doing good work. This is an important distinction.
Notably, promotion in orgs makes demonstrating non-programming skills more important than anything else. Communicating a lot, and well, is likely a much faster route to a better title and better pay than digging into fiddly technical problems and saving the day that way.
You see a mediocre junior come in and carve a shockingly-fast path up the promotion ladder without ever getting good at programming—they're communicating better, and probably, especially, a lot more. The most-visible get promoted. Talk more, email more, message more, speak up in meetings more, call more meetings. Make yourself prominent in anything process- or architecture-related. It doesn't even need to be productive (most of that stuff's not).
The sad truth of how to get paid more in most orgs.
Yes! Figure out a way to make what you did visual, or nobody will care. Front end tasks are better to take than back end, because you don’t have to do extra work to produce a demo that’s not just text and numbers (and minor GUI changes still beat all but the most impressive benchmark graph, among many crowds). Factor the extra time-cost of this (sometimes more than the time it takes to do the actual work) into your estimates, when you can.
As a bonus, people who know nothing about programming, ux, or design, want to weigh in on UI. This provides a natural opportunity to have positive interactions with them, which is a very good thing. Ask if they want to have another meeting to go over their concerns one-on-one.
I mostly agree with the points but I hard disagree with point number 3.
Clean code makes the project more easily maintainable. We generally try to keep a standard in code quality (and I would say 98% of the codebase we touch is well written). We also try to schedule refactoring rounds (but that doesn't always happen because of time constraints).
That isn't true either though. Sure, they don't care about it as a first order thing, but they care about development not slowly grinding to a halt over time. And writing well structured code is one of the things the software side of the house does in order to do a better job delivering on that desire from the business. If nobody on the technical side has the credibility or trust to make that case, then that's a problem.
>Sure, they don't care about it as a first order thing, but they care about development not slowly grinding to a halt over time.
Most only care when it affects them or sales, not when devs are asking to allot time to clean up code or pushing off a release to fix wonky stuff. In my mind that's not caring.
That's like people care that they can't walk up stairs without huffing and puffing, but not enough to actually diet and exercise. That's not actually caring, that's really regret.
I'm fortunate though, my company gives a lot of credence to dev.
That situation sounds to me like the problem of the development org not being trusted by the company's leadership when they say "this will slow down short-term initiatives but speed up long-term ones".
Yes, it's pretty common in my experience. Of course executive bonuses are granted based on short-term initiatives more so than long-term ones. When they finally reap what the sow, just blame dev. You don't get to be an executive without knowing how to politic.
> Don't get me wrong, people will expect you to write good and clean code.
I can agree with this. Clean code is not "celebrated" because it is expected as normal. You won't get a raise for it. You could get problems for not writing clean. But when the business gets into a tight spot, they will accept shitty code that fulfills their desired goal over a nice clean and elegant solution delivered few days later. In this case, the shitty code could get you a raise.
> Meetings are an important part of the software development job.
Imagine the folks building the Linux kernel or other popular, successul, and mission critical software projects sitting in meetings all day long.
I genuinely think that meetings are the only way management can justify their existance and therefore commercial projects consider them as an "important part".
>> I genuinely think that meetings are the only way management can justify their existance and therefore commercial projects consider them as an "important part".
reply
Wait until you join management at some point in your career.
I did. And held few and to the point meetings. I could see how non technical managers were struggling, and that’s how i know that some are simply clueless and serve no purpose within orgs. I managed a somewhat small number of devs - roughly 40, some distributed.
> 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.
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
The point about "incompetent people" is a bit harsh. "Competence" is rarely boolean - some people are smarter, some are less smart, but may have other qualities (e.g. being more thorough), some may not be that familiar with a certain technology etc.; that code you have to work on may look the way it looks because it had to be adapted several times to changing requirements without enough time to refactor it properly, not because the person who wrote it was incompetent. There are already enough young developers leaving university full of self-confidence thinking they are God's gift to the job market, so maybe a word or two about giving people the benefit of doubt before classifying them as incompetent is in order. That's not to say there aren't really incompetent people, but you should avoid jumping to conclusions too early...
Maybe, but the people I have worked with have been pretty heavily bimodal, especially by the senior level - many people in the "competent" bucket varied a bit but generally produced workable code (maintainable as well as works now). But there is a distinct class of senior engineer that produces awful code that is hopeless to work with later. Most frustratingly, it does actually work for the current task so those outside the system will only see problems with the later devs to work on it.
If I say something like "I've got my sales history in a database and need to graph how many widgets I've sold over time", do you start thinking about concepts and code, or do you start drooling and typing "npm database npm graph npm widget..."?
Seasoned pro-tier for that specific sort of problem is just batch-exporting to excel and letting it do the graphing, or hacking something up in Power BI or whatever.
One point to make about thrown together solutions, in the following video: https://www.youtube.com/watch?v=TmhQCQr_DCA at time 8:32 he changes Units Sold column from Decimal to Whole Number. For the trivial example, it would probably be fine but it could also be a costly mistake in other scenarios.
We all start from somewhere and nobody was born starting from perfect.
First label your fundamental concerns. You cannot improve what you don't measure.
Error-prone code? First number the errors then classify the errors. Are your errors related to typos or do they come from not handling variable input gracefully? Now reduce your numbers by consciously finding typos, or by consciously mapping out just what inputs could possibly come in. Miss one? Write it down and never miss it again.
Meetings? How many times do you get "well actually'd"? What specific areas do you get asked questions about?
Coworkers? How many times do you get asked for help? How many times do you ask the same question -with or w/o a subtle variation- more than once? How often do you reach out to just shoot the shit? How often does someone approach you for water cooler talk?
Or (more likely) you just _feel like you aren't competent. Having hard numbers will go very far in getting a more objective viewpoint there.
Being wrong occasionally is human. It is not the same as being incompetent. There truly are numerous people in software engineering who don't know what they are doing at all.
On my current job, one guy took over a month to "write more tests for service X". He was finally fired (took over a year despite being clearly incompetent, and they had multiple opportunities to not renew his contract). After that, I saw that he had only written 6 tests, which were quick copy-pastes, and largely useless. Maybe this guy had some positive qualities, but writing code was not one of them.
Another guy on this small team writes garbage code. Like "if (condition) true else false". He does have some redeeming qualities, but has caused huge amounts of bugs and tech debt despite being one of the most senior devs on the team.
My code is not perfect, I've done the occasional bonehead maneuver and had dunning-kruger when I was young, but there is just no comparison. The majority of devs on this team are not shit; we know who the shitty ones are.
Nope. There are extremely incompetent software developers out there. People who are so incompetent that removing them from the team increase the productivity of the team. After 30 years of working on software teams around the world my conclusion is that 1 in 10 developers are really good and worth working with. 8 in 10 are OK for routine work but don’t let them make any high level architectural decisions. And 1 in 10 are so incompetent that they should be removed from the team.
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.
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.
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.
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.
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
786 comments
[ 2.9 ms ] story [ 434 ms ] thread"Legacy codebases" and "fun" should not appear in the same sentence.
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.
It’s all about the team.
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.
Cities are legacy projects, colonies are greenfield. Both have their pros and cons.
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'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.
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.
[^1]: https://blog.research.google/2006/06/extra-extra-read-all-ab...
If anything, I miss the linear algebra drills the most.
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.
but you're almost guaranteed to encounter DS&A courses in college which gives you a base level of understanding.
someone self-taught might not.
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."
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.
The average college course, yea not great…
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"
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.
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.
But in the end, I never regret becoming a software engineer, and I also realized that it has profoundly shaped who I have become.
I chuckled. How can someone write this with a straight face?
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.
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.
As I said in another post, is it harder than working with cancerous kids? Or being on the road for days to only see your family every other weekend?
Are you really claiming that it's easier than bickering with the PM during standup?
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).
I'm awaiting your proof on whether P is equal to NP.
(Obviously me doing those is even more unlikely than me doing P=?NP, but I'm not sure how I'm involved here.)
If it were shallow and simplistic, any moderately intelligent person would be able to do it - yet decades of world-class mathematicians have failed to produce a proof.
Especially being simplistic (unambiguous, mechanistic) is a feature for what mathematics is used for.
The list of open mathematical problems is as varied as it is vast. But even going beyond that, it's clearly evident (e.g. by considering drop-out rates of technical degrees) that most people seem to be having a really hard time even with comparatively elementary mathematics.
> Especially being simplistic (unambiguous, mechanistic) is a feature for what mathematics is used for.
I'll give you "unambiguous" up to a point (there's still enough debate about which axioms are the "correct" ones, though). But "mechanistic" is plainly wrong. The set of true theorems (e.g. of ZFC) is famously undecidable, so there can be no algorithm that can capture all of mathematics.
Also you must be confusing basic arithmetic (1+1=2) with mathematics in general.
Go read some papers on deep learning architectures or learn about the Fourier Transform then come back and tell us how shallow and simple it is.
Mathematics requires the most sophisticated and deep thinking that the human species is capable of. Very few humans have the raw intellectual capacity required for being a productive mathematician.
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.
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.
In all cases the managers were completely understanding about the mental impact of the layoffs, both for those directly affected and those who kept their jobs and would need to pick up the work of the departing. Never once did I see a manager expect any work to be done the rest of that day after a layoff was announced.
If you ever work for a manager who isn't compassionate during a layoff, I'm sorry, that sucks.
Getting a job in the first place is actually the hardest job of them all, even in the US.
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.
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.)
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.
Yeah having kids fixed that for me
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.
The practical side is clear: close the laptop. But on the mental side I do wonder where the right balance is. I've recently started to forget about work at the weekends to the extent that - usually late on a Sunday - I suddenly remember I have to be at work the next day, which is an odd sensation. Probably just getting old(er).
And if the company will fail or you would be negatively judged for only working on business hours, there are always other jobs.
Writing down a shower thought that hits you out of your subconscious is one thing, but actively considering work topics off work time is working more for the same pay.
My interactions with colleagues are pleasant enough that I don’t need to worry about them at home. And things like “resource allocation” happens on work time
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.
* 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.
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.
and you can't just quit. you quit, your visa immediately reworked, as tied to your employer. and again. deportation.
Personally, if I shut my laptop there is no way to contact me for work related issues nor should there be.
That’s hideous. If you are going to carry it around everywhere anyway at least use your work phone for everything. That way you get at least some of the upside (work pays for it).
The problem is not that I can’t stop work. I can sit around for a week and nobody would notice. It happens.
But when I do work, I care. I want it to be nice, beautiful and make everyone’s lives easier. And I want that now. I cannot just flip those switches off when I go home (or am home, when doing wfh). It would probably be objectively better if I rested my mind a bit, but my work happens in big bursts.
Only way to find peace with this mindset is to go all-in on your own dream(s) not your boss' dream. May require a leap of faith...
Isn't that a truism? If you only work, there is not much time for anything else, I think.
It is obvious from a Birds Eye view, but those stuck in the toil rarely understand that they are losing their chance to build a meaningful life apart from work.
Clearly that's not the case for everybody. Don't assume that your reality - and what works for you - is universal truth.
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 do wonder whether this was escalated, to either the previous team lead, some other manager, or just a shouting match in the corridor.
I told him what I had done (which is easy to show in a git show commit_id) and I guess he responded to them saying that we would not revert the change.
In general I prefer to not have in person discussions for conflicts, so that there is a trail left behind, and I can take hours to respond, so I don't get heated up.
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.
It is. commonly known that some good developers make poor leads. Could some poor developers make decent leads?
After all, most serion management has never seen an if-clause, are they any better than this guy?
This would make a very poor team lead. Imagine this person taking the wrong path, then refusing to acknowledge so. Imagine them upset that "their" path was being constructively criticized.
This is how companies go bankrupt, how months or years of work result in garbage.
They looked at complaints about this dude's behaviour and go "clearly one of us!" ^^
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".
don't blame the player, blame the game.
I certainly don't, I'm fine where I'm at (software architect).
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.
How big was the team? What were their responsibilities?
I have worked places where, because of bad management, we dropped everything to shift to other tasks so often that it was nearly impossible to estimate anything.
They seem to have a lot of spare time and work on toy projects often.
Matt Levine wrote another epic LOLfest about a similar topic yesterday. [0][1]
I recommend subscribing to his column as the email is always full length piece without the paywall.
[0] https://www.bloomberg.com/opinion/articles/2023-11-07/bridge...
[1] https://archive.ph/CQUn9
Edit: seems to be an issue with DNS over HTTPS, change provider from cloudflare to nextdns solved it (per https://www.reddit.com/r/AskTechnology/comments/162w00q/gett...)
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.
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.
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.
That has not been my experience...
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?
And this is the first issue you should have mentioned! All the rest is peanuts...
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.
Corollary 4: Never buy version 1 of anything.
This kind of company is often run by people who think "People don't buy x.0 because they're afraid of bugs, so always ship x.1 as though we fixed the bugs." while failing to actually do the QA to earn that version bump.
Which predictably results in customers refusing the company's x.1 because, in their own words, "I'm not going to pay to be their beta tester.".
Surprisingly, it didn't work.
He might be really good at type systems!
That said type obsessed people invent things like property based tests (basically fuzzers for math people). They test the shit out of their code!
A senior who can't navigate the politics around estimating is missing key skills. But they still can't estimate. To estimate something you have to know what you are building and the steps to take to build it in advance. Senior engineers usually don't have enough political weight to stop that changing half way through a project and therefore cannot provide estimates. They can estimate hypothetical scenarios that are unlikely to happen.
Of course the only way to obtain a precise measurement is to start the clock and do the thing.
Estimate, multiply by 4, give the number.
- 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.
This. It helps to realize that when someone asks "how long will X take". What they are actually asking is "When can I rely on X being done by?". If you say 2 days and it takes one, no problem. But if you say one and it takes 2, they've already told the client it'll be done tomorrow, arranged for the machinery to be in place, and now everything is jammed up based on your delay.
Estimating is as much art as science and requires understanding the context around the estimate and how it will be used.
This stuff is fluid but too many technical people feel as if it's not.
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.
Uhhhhhhhhhhh....
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.
Of course there could be a fire on-route causing a jam that turns your 15 minute trip into 2 hours, but that's sufficiently unlikely it's probably not worth building into your estimate (but could be depending on the stakes involved! If someone is going to die you should probably factor this in so we can plan for that contingency). In that instance instead you need to communicate when it happens so that everyone involved can recalibrate.
Yeah, I had a PM who taught me to do this by doing it themself. My estimates are actually just doubled from how much I expect it to take when I know the design and can work with no distractions.
I’ve also worked with managers who “negotiate” as others sometimes describe. Of these I see good and bad. One who was aware of short- and long-term goals of our team and asked for estimates so they could decide what features we need to include; another who already promised the features and the deadline and is asking me to tell them that they did not overpromise despite my observations. (“I don’t believe I’ll be able to deliver those features by that date.”)
Others in between, including some who don’t like being told explicitly that I double the estimate. Worse still, the one who halves it as if to correct for some mistake.
I guess the moral is that developers aren’t the only critical party when it comes to communicating estimates. Managers do their own job; good, bad, or otherwise.
-------
> depending on my audience
Other than some managers I assume another developer or a good technical manager, and it’s a good approach. Sounds at least similar to explicitly stating that you doubled your “no distractions” estimate. Too bad it seems that an unfortunate lot of people work with the bad “negotiating” type who might even be so disrespectful as to correct their co-worker’s mistaken opinion -- which they asked for!
(Not to leave this as advice for the parent commenter. Just wrote some thoughts and figure I can share for anyone who might get value from them.)
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?"
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).
The issue is that there's a fluidity in that thinking that many many MANY technical people either don't have or don't employ.
As for negotiating estimates down, it is up to technical leadership to refuse to do that. Not easy, but doable.
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.
Really, you just have to be a pessimist. Instead of saying what people want to hear (it's simple and can be implemented quickly), you need to imagine the long-tail worst-case scenario where everything that can possibly go wrong goes wrong, then give that number. If people don't give you a somewhat incredulous look when you give an estimate, you probably were too optimistic. Just remind them that you're imagining a worst-case scenario and say that you hope to have it done sooner, but don't back down on your estimate.
Another thing to realize: at the business level, deadlines are often picked arbitrarily to create urgency. The specific date of the deadline is usually less important than just having some deadline, any deadline, to motivate everyone. Business people will pretend the deadline is Very Important, but it's all an act, more or less (arguably it's a necessary one). Remember this when giving your estimates.
disagree, not all tasks can be estimated accurately depending on circumstances but this does not imply that it's impossible to estimate any task accurately.
Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before. Better make some coffee…
Some version of this can always happen, and as a task gets larger, it is almost guaranteed to happen multiple times in multiple variations. Since you don’t know what problems will arise, there is no way to know how long it will take you to fix them. You can stay up all night in order to pretend that your “quick and easy” estimate was accurate, but that only takes you so far.
What if, while cooking dinner, a meteor crashes in my kitchen and so my estimate of 30 minutes to cook dinner turns out to be incorrect? That _obviously_ means the conclusion is that it's impossible to accurately estimate how long it takes to cook that dish so we should never do so.
There has to be a name for the type of reply your post represents.
Both have been documented to have happened, yet somehow you didn't seem to think that should be taken into account when considering estimates for cooking and pissing.
If your shit is breaking so often you're afraid to give an estimate, that's a you problem.
And yes, we had an internal team that w/i the last 6 months couldn't go a week without a deployment problem. Ask me why they no longer have that issue.
This ends up coupled with the fact that practitioners (of anything productive) tend to think in terms of 50-ish percentile estimates (i.e., there's a 50% chance this project is done in this amount of time), whereas business people care about 90th-99th percentile estimates. In software, the difference between between a 50th percentile estimate and 90th percentile estimate can be more than an order of magnitude in time spent.
If your shit is breaking so often it's affecting your willingness to estimate, that's a you problem.
I'm driving to another state for the thanksgiving holidays, and I have an estimate for how long that will take. Is it possible when I walk out to my car that the battery died the night before? sure. Am I going to factor such an unlikely event into my estimate? no. Does that imply it's impossible for me to accurately estimate how long that trip is going to take? No it doesn't.
Only in software could someone be using a tool that constantly doesn't work and they never consider replacing it or fixing it. Imagine if a carpenter showed up to your house with a hammer whose handle fell off once or twice an hour but they expected you to pay them for the loss of productivity rather than purchasing a hammer whose handle doesn't fall off.
That produces a much fatter tail distribution, because you're doing someone that no one has ever done before, and thus no one knows exactly how long it's going to take.
odd, because my experience is that your CI/CD pipeline does the exact same thing repeatedly.
Perhaps the answer to your confusion about my experience is that I don't suffer tools that hamper my productivity.
Put it another way.
I ran a raiding guild for several years and about halfway through that stint I recruited a player that raised the bar for what I thought was possible. Perhaps you need your bar raised.
This is too real.
Which is why you'll get better at estimating as you get more years of experience under your belt, and why estimating is something that seniors are better at than juniors.
Even after 20 years you may never have hooked in new library X, but I'd be willing to bet you've done something kind-of similar, and your estimate will be more accurate than a person with 1 year of experience and has never done anything remotely similar.
> Estimating things you've done a lot is trivial, and pointless.
Keep in mind you are not providing the estimate for the person who has done the task many times, you're providing the estimate to people who have never done it before. So for them, it absolutely is not trivial.
The 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)
And he could find the same amount of deficiencies in your own code. You can always find something if you search hard enough.
I'm amazed how many people in this thread seem to believe that it's literally impossible for one dev to be less competent than another, let alone by a significant margin. John Carmack is objectively a better developer than me, and by a huge amount, but I don't feel ashamed or like a lesser person because of it.
Thing is, I don't search at all. I just find them because they stand in the way of me doing whatever it is that I'm supposed to be doing instead of debugging his code.
Also, when people find a bug in my code (which does happen, naturally) I don't spend weeks trying to gaslight them into thinking there really is no bug. I just fix it :)
This is some bullshit that losers subscribe to.
As far as what the system actually tells you your job is: it's not to do good work, it's to be perceived as doing good work. This is an important distinction.
Notably, promotion in orgs makes demonstrating non-programming skills more important than anything else. Communicating a lot, and well, is likely a much faster route to a better title and better pay than digging into fiddly technical problems and saving the day that way.
You see a mediocre junior come in and carve a shockingly-fast path up the promotion ladder without ever getting good at programming—they're communicating better, and probably, especially, a lot more. The most-visible get promoted. Talk more, email more, message more, speak up in meetings more, call more meetings. Make yourself prominent in anything process- or architecture-related. It doesn't even need to be productive (most of that stuff's not).
The sad truth of how to get paid more in most orgs.
As a bonus, people who know nothing about programming, ux, or design, want to weigh in on UI. This provides a natural opportunity to have positive interactions with them, which is a very good thing. Ask if they want to have another meeting to go over their concerns one-on-one.
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).
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.
> 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.
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".
What do you think LKML is? It's a big continuous asynchronous meeting.
Wait until you join management at some point in your career.
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!).
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...
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
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.
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..."?
First label your fundamental concerns. You cannot improve what you don't measure.
Error-prone code? First number the errors then classify the errors. Are your errors related to typos or do they come from not handling variable input gracefully? Now reduce your numbers by consciously finding typos, or by consciously mapping out just what inputs could possibly come in. Miss one? Write it down and never miss it again.
Meetings? How many times do you get "well actually'd"? What specific areas do you get asked questions about?
Coworkers? How many times do you get asked for help? How many times do you ask the same question -with or w/o a subtle variation- more than once? How often do you reach out to just shoot the shit? How often does someone approach you for water cooler talk?
Or (more likely) you just _feel like you aren't competent. Having hard numbers will go very far in getting a more objective viewpoint there.
Some days, you’ll be the incompetent person.
Another guy on this small team writes garbage code. Like "if (condition) true else false". He does have some redeeming qualities, but has caused huge amounts of bugs and tech debt despite being one of the most senior devs on the team.
My code is not perfect, I've done the occasional bonehead maneuver and had dunning-kruger when I was young, but there is just no comparison. The majority of devs on this team are not shit; we know who the shitty ones are.
You haven't seen it yet. Some developers should be barred from the industry. Criminally incompetent.
And starting from scratch and college is basically the same point