Your company has been captured. It's over -- if you are quietly competent you will either have your coworkers and technical managers create a shield around you or you will find yourself outcompeted by developers who spend all of their time creating proof of work instead of doing work, and creating heavily documented CRUD apps with predictable milestones rather than challenging work where the solution is not known.
Join them if you can; dumb down your work and focus on predictable things rather than interesting work. Try to move closer to a profit center instead of a cost center because you'll get proof in the pudding there. And start quietly sending out resumes.
If you have a good manager who understands your contribution and can deal with the politics and constant demands for progress reports from do-nothing middle managers who need to send progress reports to their managers then you can probably do well until they get pushed out.
Reading the article I was agasp at the lunacy. "Prove your worth", "Publish your notes", these are the ravings of someone who has convinced themselves that it is ok for someone who has no idea what you do or how anything works to determine the value of your contribution.
I have for the longest time believed that you shouldn't be "working in tech" if you never "worked in tech". Before I'm accused of being exclusionary or elitist, I mean that you should build something or at the very least have studied in the field.
Knowing how to run a factory does not mean you know how to run a tech company. Treating devs like they are on a production line building cars is backward toilet sitting behaviour.
It is OK. That's the system. That's how capitalist hierarchies work, at just about every company, everywhere. You're an asset. Even if you make six figures, get catered lunches and unlimited PTO, you're a cog in someone else's money machine. Everybody complains that their managers don't understand how their jobs actually work. There's no reason why tech should be unique in this regard.
The key point is that if you do work for a week to track down a showstopper only to have that thrown in your face and the only reasonable response is to "cover your ass" you are doubling your work. That manager should be fired for halving the productivity of their devs.
The main point of the article is that by "covering your ass" you are actually becoming a better developer, because the prose you write is plans and documentation and gives your thoughts structure.
Hence, your personal productivity (measured by what metric?) might suffer for this one task. However, in the long run you and your team gain productivity because of existing explicit documentation and plans.
I don't feel like a cog in a money making machine. Maybe because my company doesn't earn any money (I work in public sector, improving IT security in my country and doing R&D). There are other options than corporations.
Another way out is making your own company, of course.
> Treating devs like they are on a production line building cars is backward toilet sitting behaviour.
Citation needed. At this point in time, unless you are doing groundbreaking work writing/using new software, most software engineering is really like routine factory work ("combine SDK A with library B, then plug in component C and connect to service D") and should be measured as such.
How does "fixing a tough bug for a week" fit into the factory analogy? What about "designing a new feature by drawing abstract diagrams"? These are examples taken from the beginning of the article.
If security, reliability, performance and maintainability matter (and they do, always) you need to plan your software to be data-centric. I don't see how plugging together a few libraries solve that for you.
Btw: external libraries are written by developers as well. And your developers have to not only read that code and documentation, but consider each of those a liability and a future maintenance issue. Most software engineering isn't bolting libraries together, most software engineering is about knowing how data is stored, how it is flowing, how much risk is involved with using which dependencies, who has access to what if they exploit any given section of code, and much, much more. That is why only morons think no-code tools can replace capable developers: the hard bit isn't writing the abstract cryptic text — that is in fact the easy bit — the hard bit is not shooting yourself into the foot as the complexity grows and finding a solution where all the above mentioned qualities are not in conflict with each other.
Do you work in marketing? Cause your stance would make me think your shop is a bottom-of-the-barrel bordering-to-fraud el-cheapo software house that customers instantly regret to having worked with. This is at one level with the infamous "my teenage kid can do graphic design" — which tells you more about what that person thinks about graphic design than about graphic design itself. If you are a manager you'd be wise to realize a serious software project yourself at home, this might teach you a thing or two.
> Citation needed. At this point in time, unless you are doing groundbreaking work writing/using new software, most software engineering is really like routine factory work ("combine SDK A with library B, then plug in component C and connect to service D") and should be measured as such.
This was my first thought. I don't think I've ever worked in anything "ground breaking", but I've never had work that was just "connect A to B with no thought". I mean, even if it _is_ connect A to B, you still need to consider
- Is the client (internal, external, whatever) asking for what they really want?
- Is the client asking for what they really need?
- Am I correctly understanding what the client is asking for?
- Does building this make sense for the product as a whole?
- What As and Bs can accomplish what I'm looking for (assumes they exist, per the initial assumption)
- Of those As and Bs, which ones won't run into conflicts with the project
- Of those As and Bs, which ones are well supported
- Of those As and Bs, which ones are likely to continue to be supported (long enough for our needs)
- Of those As and Bs, which ones mesh well with the current coding/development style of the project (maintainability)
- How can I best use A and B in a way that is easy to understand (maintainability)
- How can I best use A and B in a way that I can test my code without having to write 1000 lines of mock (maintainability)
- and the list goes on and on and on
Unless you're a VERY low level developer, most software development requires a large amount of thought, both analysis and planning. It is very much _not_ like routine factory work.
Heck, I spend a fair amount of my day not even looking at my screen, as I ponder how best to solve "easy" problems.
I just wanted to say thank you. As I was reading this, I cringed at the thought of even coding in an environment like this. I would like to think of myself as an extremely productive programmer, I got lots of stuff done. Lots of things built. I code in sessions, 4+ hour blocks of focus. I at least get one good session done a day, sometimes I can do a few if I feel inspired. Some of my best sessions have been at 3AM after telling the computer to go fuck itself and banging my keyboard.
This code system (in article) for someone like me is hell - but I like to build stuff. I hate fixing bugs, etc. But in "maintenance mode" or "bug fixing mode" a system like this is kind of necessary.
"The simplest and probably most widespread metric used to measure developers is how many pull requests they’re merging."
I suppose it's good practice to "backup my work" at the end of the day - I mostly don't though. If I need to fine. But I mainly push to a repo when I want to demo live, or working with a dev and we need to share. Big teams with lots of moving pieces, pushing repos each day is necessary I suppose? Or is this just bad codebase architecture? ...Small teams are more effective IMHO on smaller "modular" codebases/microservices/components/modules...etc.
Henry Ford’s reaction to a consultant who questioned why he paid $50,000 a year to someone who spent most of his time with his feet on his desk. “Because a few years ago that man came up with something that saved me $2,000,000,” he replied. “And when he had that idea his feet were exactly where they are now.
I don't think its unreasonable for somebody to be able to demonstrate they they worked the 8 hours they said they worked. Especially when a lot of the work is just "thinking".
Have you folks never worked with somebody who literally does nothing all day?
Have you folks ever paid programmers out of your own pocket?
I know agile is unpopular these days, but I've always liked daily stand-ups so I can describe what I "thought about" all day. What problems I faced. What was challenging about the design. What I discovered in my research.
Companies do have people who just burn out, get bored, or just stop working. How are you supposed to find those people if nobody ever has anything to show?
Yes, we've all worked with people like that. They are easy to identify, regardless of what kind of metrics they throw out. All you have to do is use your subjective powers of observation, and have the courage to believe this instead of trying to justify it through metrics. If you are not able to do this then no amount of process or fake metrics is going to save your development team.
In particular, if you are measuring the number of hours people work as a way to measure productivity, then you are in deep, deep, deep shit.
Yeah I have worked with someone like that, but as someone who does actual work I don't see why because of that moron I have to document every step I am taking. Feel free to come in once a day and let me describe to you what I am doing, the rest is in the commit messages.
The guy I worked with was thrown out recently. Unless you work in complete isolation your peers know you are not doing your job, and once that pisses them off enough it will be more widely known.
> What’s a more realistic scenario here? Your manager stands up to their entire chain of command...
She should try, at the very least. Otherwise you have a bad manager. Your manager's job is to look out for what's best for the team, not to answer to a chain of command. This isn't the military.
If any employee, at any level, can't have a constructive conversation with the level above about what the level above has gotten wrong, you have a busted company culture.
Remember, you, the IC, are supposed to be the expert at your programming job. Your manager doesn't have that expertise, but she is supposed to be the expert at understanding what you're up to. Her manager doesn't have that expertise, so the second line manager should depend on your manager for that information, rather than dictate down manifestly inadequate productivity measures.
Additionally, if your organization doesn't have the kind of culture where managers do this, then you should get out as soon as you can. It is the kind of place that doesn't value quality because quality is too hard to measure. Start looking for a different place and don't stop looking until you do.
A police officer sees a drunkard under a streetlamp and asks him what is the matter. He says that he dropped his keys, and the officer asks him where he dropped them. He points off to the side and says that he dropped them over there, but "the light is better here".
> because quality is too hard to measure
This is the heart of it. A common business school trope that leaks everywhere is to be data-driven. This is fine up to a point. Once you realize that you can't measure actual quality, and decide to measure something else and call it quality, you are now part of a management structure whose goal is the preservation of the management structure.
> You can't fight the culture of your leadership forever.
Depends where you work. I've been at a big company where the leadership cycled at a pretty regular pace; don't like the current leadership, just wait and see if you like the next set; in the mean time, hope for benign neglect; leadership is busy, maybe they'll just leave you alone. OTOH, I've also worked at companies where the CEO is the founder and still has majority votes --- leadership cycling was a lot less at those places.
>> Your manager's job is to look out for what's best for the team, not to answer to a chain of command. This isn't the military.
Aside from the naïve understanding of military culture, an organization full of managers looking only to promote and protect their teams is equally unhealthy. Dilbert spoke of "battling business units" whereby each team fought against one another to promote themselves. Not good. A manager must represent their team upwards to the higher chain, but must also represents the higher chain downwards. It is always two-way conversation.
> Your manager's job is to look out for what's best for the team, not to answer to a chain of command. This isn't the military.
No, your manager's job is to make their boss look good. This trickles up to making the CEO look good to the board and ultimately the investors/shareholders.
No that's just private equity, and public companies. Real companies, companies that sell stuff or services to others as the way they make money, have to deliver stuff to customers. The whole company has to answer to the customer.
I don't really disagree with anything in this post, but it's a bit sad. I understand the "why" of the scenario, but it will never not be frustrating to me when I have to "prove" that I'm creating value because I didn't tailor my work to optimize for whatever system the company is using.
Like, I just want to solve problems with code, I hate that I also have to constantly advertise how smart and useful I am because managers are so myopic that they can't figure out if I'm valuable.
It brings out the worst in people; you get people holding meetings about stuff that could be summarized in an email in order to give the illusion of working hard. Pages and pages of documents that will never be read are created because if you don't create them then it's hard to say you were doing stuff. Hundreds of tickets pile up in Jira that will never get done because you need to give the appearance that you're actively important in the improvement of the product(s).
I get it, it's the world we live in, but I don't have to like it.
It's not that your manager can't figure out who is valuable. They probably have a good idea about that. What they can't easily do is protect or promote people whose metrics don't fit whatever KPIs that the senior leadership are currently pushing as essential.
I have to get my team to do the things the company expects, even when it's dumb or annoying. I can't get good bonuses for people who aren't visibly hitting the right targets.
Unless your total mission in life is to reform the company (good luck with that), you go with the flow. Having a good rant about it helps sometimes. But managers don't have much power to change the whole system.
It also makes me sad that someone is earnestly and honestly trying to hack through these weeds, when someone with the gift of the gab will sit in that performance review, jazz hands their way through it, and go for a barbecue at the manager’s house that weekend, while having done precisely 22 minutes of arguable work in the last quarter.
I mean, I know. I’ve been that asshole. Useful to still have a paycheck while you’re getting a startup off the ground. I got so much practice at “the dog ate my homework but here’s a fresh coffee” as a kid it was ridiculous.
I had a job once where my manager and the CEO were both fairly frequent smokers, and so the people at the company that smoked would go outside and join them on their smoke breaks. I noticed that these people were frequently the ones who got bonuses and the benefit of the doubt compared to the people who didn't smoke, I think simply because they had more exposure with the leaders.
I didn't (and don't) smoke, so it was always a bit awkward for me. I suppose I could have just hung out with them as they smoked and I didn't, but I never did that.
Yeah, I literally took up smoking for business. British retail magnates pretty much all chain smoke. Going and hanging out at the smoking area at a trade show was a great way to meet prospects, and more than a few deals were shaken on while we nipped out of a sales meeting for a fag.
This stuff may happen, I can't say it is untrue, but I've never seen a manager terminate a decent to good programmer because they didn't understand their workload.
The companies I've worked for spend a lot of time recruiting talent. If a manager wanted to can someone because they didn't know that fixing bugs takes time, it would be the manager in front of a more senior manager demanding they explain their logic. Also, if you've managed programmers or SW projects for any amount of time, you'd understand why things take time.
Most folks I've seen get terminated is because the company is shrinking, or they are not performing or they are a jerk and/or violating company policies.
My thoughts are do the best work you can, be nice to others and you'll be fine as long as the company is making money. Don't worry about 'metrics', people generally know who's worth keeping based on more than that alone.
> This stuff may happen, I can't say it is untrue, but I've never seen a manager terminate a decent to good programmer because they didn't understand their workload.
This happens all the time. It just doesn't look so obvious.
In practice management will push the developer to communicate and document and justify the work. If the dev complies, they find themselves spending most of their time on the overhead. Welcome to big software enterprises where very little gets done.
If they don't comply, then management will keep adding pressure and eventually get rid of the developer because of "behavioural issues".
I once heard someone say a phrase which feels relevant to this article:
"If you know nothing of what they are doing, you suspect them of doing nothing".
I've used this sentence to catch myself over the years where I've been quick to judge someone as doing nothing at their job or day-to-day, and then used it as motivation to (if possible) learn about what their days actually look like. I'm almost always finding out I just didn't know enough about what they did.
As the article points out, this goes the other way too. It doesn't matter how good you are at your job if nobody at a decision making level understands what you are doing.
Keeping a paper trail of what you've done in the ticket, issues you came across, and questions you've had while working on something, even if you were able to answer them yourself is great advice that really separates junior from senior devs.
I do a lot of documenting but not for the paranoid reasons in the article but to leave breadcrumbs for any person, including myself, who might need to look for information in the future.
I've worked long enough to get absolutely tired of yet-another-archaelogy-trip to figure out business logic, a reason for that weird counter-intuitive implementation, how exactly a bug was detected and fixed, why the architecture looks this way, so on and so forth.
It's one of the most draining and stupidest part of this job.
When I bump into someone's else work who diligently left breadcrumbs scattered around; in commit messages, PR descriptions, comments, history of tickets, etc. I almost literally jump with joy.
It's a gift to the future that I really enjoy paying forward, hoping I can instill this feeling unto someone else, again: including myself.
Nothing makes me more sad than seeing a PR with the default description like 'Closes FOO-123'.
Conversely nothing makes me happier than an informative description especially when it states how the PR was tested. Sometimes I don't even need to look at the code.
Yep, "visibility" and "impact" (oh, how I loathe those words) are everything in a competitive environment or when management is looking to make job cuts. If your manager can't make the case as to why you are more important to the organization than your co-workers, your employment hangs by a thread.
100%. Consider a scenario where someone with too much money accidentally is forced into buying out your company and then they decide to cut 75% of the workforce. At that point it's all metrics, good or not, that decides who stays and who goes.
>Are these tools measuring the “right” thing? It doesn’t matter!
Eh, not always. Sometimes it's truly random. For example, at one of the recent Google layoffs, they fired a guy who was oncall. He just woke up and didn't have access to his email anymore, even though he was supposed to be responsible and react to any issues in some service.
Layoffs and PIPs are very different. The former is random, or at least the decision is made at the top of the organization by someone who probably doesn't know who you are. The latter is about your specific performance.
> If management is measuring pull request (PR) throughput, is it really so bad that developers start pushing through smaller PRs? God forbid we end up delivering value faster with fewer defects, better testing, and more thorough peer review.
This one bothered me. Because increased pull request (PR) throughput does not, in ANY way, imply "fewer defects, better testing, and more thorough peer review". In fact, it probably implies the reverse; just writing the smallest amount of code you can to get it out the door, then coming back and adding to it later. Edge cases? Next PR. Automated tests? Next PR. Comments? Next PR. Maintainability? Next PR. Taking the time to make sure the feature you're working on makes sense? That's not a PR, skip it.
Measuring PR throughput is the same as measuring lines of code, effectively. Nothing about increasing either one of them implies adding real value.
> If your manager can’t see it, it doesn’t exist when performance review time rolls around.
I've become very jaded around performance reviews. A number of years ago, I worked my butt off putting in insane hours and being extremely productive. I knew that I deserved the highest performance rating possible. And in the review my manager agreed that that was what I deserved, but instead I got a successful rating - completely middle of the road average. I was shocked. My manager informed me that HR specified what percentage of each rating they were allowed to give out and that he had had to give the higher ratings to other employees for various reasons. Ever since then, I've done the bare minimum of work to get by. Why work my butt off to get a successful rating when I can do the bare minimum and get the same rating?
I recently quit a job, for a large number of reasons, but the one most relevant to this post was the topic of my github numbers. My manager gave me a "needs improvement" review, citing my "bad numbers" and comparing them to several of my teammates. Their numbers, to me, were laughably high.
I thought I was doing pretty good on PR reviews. I do one or two a day. I read the description, sometimes more than once. I read through the practical testing steps. I follow them, sometimes with a lot of setup required. I really make sure it does what it's supposed to do. I read the code, line by line. Sometimes before I do the practical testing, sometimes after. But I read through the code, several times. I don't know how you wouldn't. Functions are calling other functions I haven't gotten to yet. So I read through the code multiple times. I don't just try to understand what it does, but why it does what it does. Is there a better way? Is this going to change or impact something else it should or shouldn't? A good code review can easily take an hour or more, in my humble opinion. Two reviews a day on top of all my bs meetings and I still have my own shit to do. How does my teammate have triple my PR reviews for the quarter? Seems crazy.
One day I'm pair programming with one such teammate. We finish the task, I create a PR, write a description etc. I press the ready for review button and start to say, "see you later bla bla" and suddenly there's an approval on the PR. It's been 5 seconds, tops. It's the other teammate with 10x code ninja numbers on the team. I remark that approval was pretty quick. My teammate forces a nervous sounding laugh. They work together ever day and seem pretty close, huh.
Anyway, after that, every morning after I made coffee and opened my laptop I'd spend 10-15 minutes just going down the list of open PRs on the project and approving them. I didn't look at the code or even bother reading the description. I just approved them all. I also started opening PRs for stupid shit like minor typos in comments that I'm quite sure no one even reads.
My next review my manager said I had made some impressive improvements and gave me a "meets expectations".
I'm looking for a job in a different industry now. I'm not out of software development, I just don't think I can work on another e-commerce webapp company run by MBAs again. I think I'd rather be broke.
I think this comes down to a lack of shared understanding on what a PR approval means, it sounds like you didn't believe it meant the same thing as your team did. There's not one standard meaning of the "rubber stamp". It's a culture thing and teams should discuss and eventually agree on what they think it means. Mature teams will have guides, checklists and documented expectations.
It's moderately likely that behind the scenes someone was complaining to your manager that you were blocking their work and that the "metrics" discussion was just a cover for that.
Usually when I review a PR I am just sanity checking the overall approach, figuring out or asking how they tested it, and making sure there's nothing crazy that will cause pain for everyone else later. Detail correctness I don't consider my problem because there's no economic way I can verify it. I can usually approve in minutes and I don't consider it a waste of time, I did the things the process needed of me.
Unless something irreversible is happening (and it should be reviewer's job to be aware of that), the fix for a bad PR is more PRs.
There are projects where almost the only thing that matters is approving quickly because this will let your co-workers get on with their job, this culture tends to evolve in orgs with lots of related repos where you need 5 MRs and pipelines (that flow on to each other) to deploy the tiniest unit change. It's completely dysfunctional but it happens a lot.
I imagine there are places where reviewers are expected to spend an hour "raising the bar" on every PR but I've never worked at one. I'm also not sure if I'd want to.
Note that there's not one thing or process that makes sense, it's very context dependent with lots of exceptions. For example, if someone from a "far away" team is contributing to a particular repo for the first time I will probably reach out to them to see what they're trying to do and review more carefully because they likely have limited context vs a core contributor.
Well then why does the PR template used at the company require manual validation steps on every PR if it's not expected that reviewers do them? Do you really think 5 seconds was enough time to "sanity check" the PR? Do you think 5 seconds was enough time to even click the code tab? Why are two "reviews" even required if the reviewers are actually expected to simply rubber stamp every single PR that comes through?
Edit: "the fix for a bad PR is more PRs" has got the be the worst take I've seen in years.
The review requirement often comes from compliance, many standards require a control to stop developers getting code into production by themselves without anyone else looking at it. Sometimes it's because an engineering manager read a book that said it was "best practice" or because "that's what we did at $lastjob". Sometimes it's because someone set up the SCM to require it and never looked at it again. Maybe it made sense to someone 5 years ago but it doesn't make sense now, for the teams and processes you have. It's worth asking and finding out!
I agree 5 seconds is not enough for even cursory review, why even bother, unless it's a compliance thing. In a functional team the thing you do is raise this in retro and discuss what everyone expects and wants from reviewers.
If your take is that blindly approving merges with 0 care is actually a good thing and that I "lack understanding" then I simply have to disagree lol. Good luck with that.
Sorry that I was not clear, my bad, I did not mean to imply that you personally "lack understanding" in any way.
What I should have written was that there seemed to be a lack of shared understanding among the team, (i.e, agreement) on the value, meaning and expected process for PR reviews.
I don't think there is any particular level of care that makes sense in all cases for PR reviews, I believe it depends on industry, criticality, the particular repo and who is doing what. I think the most important thing is that everyone is on the same page about what's expected.
I've had great success with gitlab and it's issue + mr (they use "merge requests" which tbh feels more appropriate) tracker. I make an issue ticket, dump all symptoms, logs, relevant configs, whatever into it. Then I make the MR, and put all my fix stuff in there. I like the separation of what the issue was vs what the fix was, while still keeping them linked. Really helps when somebody else does the other half.
ETA: none of this is as helpful as having my team and higher ups understand and appreciate what I do, though. That's step 1. Or step 0 if you can feel that out in the interview.
Agreed. That's why the documentation is important. If the issue ticket says "I saw this but once. It took 2 days of reproducing and it could only be done if the moon was in a waning phase while 3 dogs bathed simultaneously" and "this is the log dump. You can see on line 3453 that we segfault" etc, it shows what you've been doing.
The way I felt the article should be interpreted is that yes, if after 2 weeks you have a 1 line change, that's going to get you fired. And debatably it should, given that it'll likely take somebody else another 2 weeks to fix a similar problem. Why would a manager want to pay 2 weeks salary for (what we call, unsure if commonly used) "tribal knowledge"? At least do a post-mortem/lessons-learnt
Oh yeah the branches too. It's made it super easy for me to ticket the issue, maybe the MR + branch in one click, and add it as a worktree. Honestly worktrees have saved my multitasking. I know Jira/Bitbucket do similar, but that's not what I primarily use.
> If management is measuring pull request (PR) throughput, is it really so bad that developers start pushing through smaller PRs?
So, just the previous week I've made 5 small PRs, all of them working on the same certain "area" of the code base but different pieces of it. Two of those PRs touched almost every single corner of that "area" (differently structured error reporting and differently formatted logging) another one had a rather sizeable refactoring and code movements between three major files of that code area, and as for the two remaining ones, one absolutely depended on the other but could not be done in the same PR because of how the JIRA issues were structured (i.e. "PROJ-9004: Make it do foo", "PROJ-9005: While foo from PROJ-9004 is happening, make it also do bar").
I've also made a decision to not order those PRs sequentially (i.e., base the next PR on a previous PR), and instead branched each PR from the dev trunk and went to work on them. As a result, I've increased the work I had to do approximately by 50% because of the merge conflicts I had to resolve. The reviews combined took about twice as much time as a single big review of all five changes in one PR would've probably taken. The QA took about five times as long since QA did full regression of that code area 5 times instead of 1 time; they've also almost missed an error in the 4th pull request because of all the repetitiveness.
All in all, 10/10, recommend it if you need your coworkers to get lost in the maze of similarly-themed little branches, all alike.
Do those things if your current job require them, but at the same time have a plan to leave this hellhole as soon as possible.
Those kind of places value more effort, or worse, the appearance of effort than the results. So, act accordingly, but leave as soon as you can.
>They have tools that will suck up data from literally every possible source available. And these tools are getting better every year. Tools like Jellyfish, CodeClimate, Quantive, and if your organization is old and rich enough, plenty of homegrown stuff. If you’re unfortunate enough to live in the United States, they can legally install a keylogger on your laptop.
This is why my next project is a programmable HID bluetooth device that simulates key strokes and mouse movement. Imagine hackertyper.com but from a device instead. Because your corporate surveillance metrics are bad and you should feel bad ;)
Kind of sad that paperwork is more important than work.
In my experience I don't want to be in companies that have this culture, and I take my contributions where I don't have to constantly prove myself.
In other words, if you are not excited to work with me, I am not working for you.
Too much feudalism mindset in especially the US workforce is hampering wide-scale productivity.
If your work environment is not win-win and you're managing optics to avoid getting fired, just go where your coding talents are valued & be a happy person instead.
> Kind of sad that paperwork is more important than work. In my experience I don't want to be in companies that have this culture, and I take my contributions where I don't have to constantly prove myself.
Welcome to Bullshit Jobs. People are being forced to be stressed about absolute lunacy.
Blogging and writing lots of white papers has become one of my favorite techniques for this in IT. Pretty much anytime something really interesting happens, I'll spend some time carefully writing up a detailed explanation. I often find myself surprised by my own findings when I re-read them months later.
> Your manager...“I don’t [know how it goes]. I went to business school.”
There's the problem.
Organizations whose leaders aren't able to discern your actual value are going to be miserable places to work. You play their games or baffle them with BS. But you don't get to attain any sort of authentic actualization.
...
Take my pessimistic commentary with a grain of salt. I'm job searching at the moment for a software manager role and the opportunity landscape is a wasteland of b2b insurance widget companies, usury companies, and AI dead-ends. If you want to build things that help real people, you may have to DIY.
If someone told me "I don't know. I went to business school", I'd then ask "So why are you managing programmers, shouldn't you be managing business people?"
But all joking aside, I think there are few MBAs so dense as the one portrayed in this article. Sadly, I'll probably be proven wrong...
Somehow software engineers can be as dense as the MBA in the example.
I had a manager who used to be a dev. He remarked that a certain teammate is really productive and gets so much done. I asked how he knew and he said that when the teammate is on call he is able to close a large number of tickets.
I showed him that the teammate just closed all the tickets as “self resolved” or “can’t reproduce”.
>>“Well I fixed that showstopper bug! And everyone agreed it had a big impact.”
>>“It looks like the fix was just one line of code.”
>>“Yeah but it took me two days to find that one line haha, you know how it goes.”
>>“I don’t. I went to business school.”
Was this article written by a LLM? Coze that's the most made-up, cliché, unrealistic, middle school parody-level perception of how businesses operate.
Any reasonably large and old company with a software base will have a god-awful overengineered incomprehensible duct-tape wrapped ball of mud that needs constant pampering and costly maintenance. With most task being very much "find the needle in the haystack" type, with the needle being that "one line" indeed but the problem in finding it being, obviously, the haystack. And this "needle finding" being that one thing that totally and definitely all this AI hype can't do shit about. Literally nothing, all those 700 billions burned into LLM training are absolutely orthogonal and useless with respect to the real problem maintenance and development of legacy software (that is most software) poses.
Create a paper trail. Crank out tickets. Document everything. Hit the numbers.
No.
Add value. It's not your job to quantify it. It's not your job to create an understanding of what you do.
If your organization or your manager specifically does not recognize your contributions, be happy to move on.
If you get feedback that says "we recognize your value, but we really need x" that's reprioritization. Respond appropriately. If documenting your value in that way prevents you from actually being valuable, be vocal about it. If it's just a pain and you can still do your job, then suck up the pain like everybody else.
I've been in large engineering organizations. They want to quantify everyones value so that there's "fairness". BS. There is no large scale way to determine of a software engineer is good at his job or productive. Yes, some people have more opportunities to affect the bottom line than others. Yes, some people have easily quantifiable work. That's how the world works.
Have they figured out a way to recognize and effectively incentivize good teachers? Not in my 51 years.
Have they figured out a way to recognize and effectively incentivize good CEOs? Nope.
What makes you think that we should be that easy to stack together and figure out?
I'm senior. I'm experienced. I'm valuable. I'm not always right, and I am not always valuable. In the end, I've had a good and healthy career focusing on the things I'm good at and the things I care about while letting other people figure out if I'm worth what I cost to keep around. Some of those people made good decisions and some bad ones. I still moved forward and my kids have always had food on the table. I say that's enough.
the most unproductive places I have worked - ran according to what OP says and some of the comments etc. things that should take a week took 6 months due to bureacracy and everyone covering their ass and documenting details that don't matter. because after all - they have to account for your time.
the most productive n best place I worked at - whether the work was delivered after 5pm or at 11pm - as long as it was quality and delivered that's all that mattered.
thing is most software engineers don't think like "business-men" and just as Jay-z said "i'm a `business` man" not a "business-man". Be a business, then "business-man" then lastly a jira ticket pusher. Jira ticket pushers lives are miserable -- you get hazed over leetcode, you have to be pretend-nice to your fellow jira ticket pushers because of 360-review etc.
learn to look at other industries and see if they play those stupid games.
In other news, I’ve had pretty good luck when trying to build culture by getting people to measure both the act of practising the behaviours and the overall expected outcomes, but not setting specific targets on the teams. Measuring the outcomes for individual teams leads to “checklisting” rather than behavioural change.
My experience has been a little different. Usually you have regular one-on-ones with your manager where you discuss career things, including what you've been working on lately. From being in the manager shoes myself, I do this so that you and I are more ready to advocate for you when it comes to actual performance review time.
> “Yeah but it took me two days to find that one line haha, you know how it goes.”
> “I don’t. I went to business school.”
The conversation should end right here.
They don't know what they are managing, why fixing things is unpredictable, and worst of all - they are communicating AFTER the fact, one month later - which is too late.
The manager needs to be fired for incompetence and incapability. But this is not how tech companies work - leading to all the management hate.
We've gone from "You don't get promoted if you don't show clear visibility for the things that you do" to "You can get fired for not showing clear visibility for the things that you do".
The first is true. The latter isn't.
There are dystopian black swan events like the richest person in the world going on a ketamine binge and buying your company and dragging everyone into a meeting room with printouts of examples of your code.
Unless you're involved in one of those, noone gets fired for doing a lot of things but not tracking them enough in JIRA to cover your notes.
Most teams know who on their team gets shit done and who doesn't. They also know the ones who get things done without a clear track record of it. They are asked to help with every problem, and are constantly too busy to get their own stuff done because they're helping everyone else with theirs. Yes, they struggle to get promoted, but they certainly don't get fired.
The people who get fired are the ones who THINK they're in that group, but they're talkers, not do'ers. They get fired and everyone shrugs and goes "oh well, anyway."
Then they go and write blog posts like this to help precisely the wrong type of person that needs this advice - cargo culting impact. Becoming allegiant to process for the sake of visibility.
It'll certainly lead to more clutter and confusion in the world and in the tracking systems.
Might as well write blog posts about how to pad your line counts in your pull requests so that people looking at your Github graph at performance review time think you did more than you did.
Your company has been captured. It's over -- if you are quietly competent you will either have your coworkers and technical managers create a shield around you or you will find yourself outcompeted by developers who spend all of their time creating proof of work instead of doing work, and creating heavily documented CRUD apps with predictable milestones rather than challenging work where the solution is not known.
Join them if you can; dumb down your work and focus on predictable things rather than interesting work. Try to move closer to a profit center instead of a cost center because you'll get proof in the pudding there. And start quietly sending out resumes.
If you have a good manager who understands your contribution and can deal with the politics and constant demands for progress reports from do-nothing middle managers who need to send progress reports to their managers then you can probably do well until they get pushed out.
This resonates so hard with me.
Reading the article I was agasp at the lunacy. "Prove your worth", "Publish your notes", these are the ravings of someone who has convinced themselves that it is ok for someone who has no idea what you do or how anything works to determine the value of your contribution.
I have for the longest time believed that you shouldn't be "working in tech" if you never "worked in tech". Before I'm accused of being exclusionary or elitist, I mean that you should build something or at the very least have studied in the field.
Knowing how to run a factory does not mean you know how to run a tech company. Treating devs like they are on a production line building cars is backward toilet sitting behaviour.
It is OK. That's the system. That's how capitalist hierarchies work, at just about every company, everywhere. You're an asset. Even if you make six figures, get catered lunches and unlimited PTO, you're a cog in someone else's money machine. Everybody complains that their managers don't understand how their jobs actually work. There's no reason why tech should be unique in this regard.
Yes and no.
The key point is that if you do work for a week to track down a showstopper only to have that thrown in your face and the only reasonable response is to "cover your ass" you are doubling your work. That manager should be fired for halving the productivity of their devs.
The main point of the article is that by "covering your ass" you are actually becoming a better developer, because the prose you write is plans and documentation and gives your thoughts structure.
Hence, your personal productivity (measured by what metric?) might suffer for this one task. However, in the long run you and your team gain productivity because of existing explicit documentation and plans.
I don't feel like a cog in a money making machine. Maybe because my company doesn't earn any money (I work in public sector, improving IT security in my country and doing R&D). There are other options than corporations.
Another way out is making your own company, of course.
> Treating devs like they are on a production line building cars is backward toilet sitting behaviour.
Citation needed. At this point in time, unless you are doing groundbreaking work writing/using new software, most software engineering is really like routine factory work ("combine SDK A with library B, then plug in component C and connect to service D") and should be measured as such.
"...combine SDK A with library B, then plug in component C and connect to service D..." is "really like routine factory work"?..
What kind of "routine factory work" you've been doing?
How does "fixing a tough bug for a week" fit into the factory analogy? What about "designing a new feature by drawing abstract diagrams"? These are examples taken from the beginning of the article.
This is naivity on "cryptobro"-levels.
If security, reliability, performance and maintainability matter (and they do, always) you need to plan your software to be data-centric. I don't see how plugging together a few libraries solve that for you. Btw: external libraries are written by developers as well. And your developers have to not only read that code and documentation, but consider each of those a liability and a future maintenance issue. Most software engineering isn't bolting libraries together, most software engineering is about knowing how data is stored, how it is flowing, how much risk is involved with using which dependencies, who has access to what if they exploit any given section of code, and much, much more. That is why only morons think no-code tools can replace capable developers: the hard bit isn't writing the abstract cryptic text — that is in fact the easy bit — the hard bit is not shooting yourself into the foot as the complexity grows and finding a solution where all the above mentioned qualities are not in conflict with each other.
Do you work in marketing? Cause your stance would make me think your shop is a bottom-of-the-barrel bordering-to-fraud el-cheapo software house that customers instantly regret to having worked with. This is at one level with the infamous "my teenage kid can do graphic design" — which tells you more about what that person thinks about graphic design than about graphic design itself. If you are a manager you'd be wise to realize a serious software project yourself at home, this might teach you a thing or two.
If this is the type of work you are doing, your job is 100% going to be replaced by AI.
> Citation needed. At this point in time, unless you are doing groundbreaking work writing/using new software, most software engineering is really like routine factory work ("combine SDK A with library B, then plug in component C and connect to service D") and should be measured as such.
Citation needed.
This was my first thought. I don't think I've ever worked in anything "ground breaking", but I've never had work that was just "connect A to B with no thought". I mean, even if it _is_ connect A to B, you still need to consider
- Is the client (internal, external, whatever) asking for what they really want?
- Is the client asking for what they really need?
- Am I correctly understanding what the client is asking for?
- Does building this make sense for the product as a whole?
- What As and Bs can accomplish what I'm looking for (assumes they exist, per the initial assumption)
- Of those As and Bs, which ones won't run into conflicts with the project
- Of those As and Bs, which ones are well supported
- Of those As and Bs, which ones are likely to continue to be supported (long enough for our needs)
- Of those As and Bs, which ones mesh well with the current coding/development style of the project (maintainability)
- How can I best use A and B in a way that is easy to understand (maintainability)
- How can I best use A and B in a way that I can test my code without having to write 1000 lines of mock (maintainability)
- and the list goes on and on and on
Unless you're a VERY low level developer, most software development requires a large amount of thought, both analysis and planning. It is very much _not_ like routine factory work.
Heck, I spend a fair amount of my day not even looking at my screen, as I ponder how best to solve "easy" problems.
He's role playing the manager role in the article, hopefully sarcastically.
says the person who never devised a clever algorithm in his life
I just wanted to say thank you. As I was reading this, I cringed at the thought of even coding in an environment like this. I would like to think of myself as an extremely productive programmer, I got lots of stuff done. Lots of things built. I code in sessions, 4+ hour blocks of focus. I at least get one good session done a day, sometimes I can do a few if I feel inspired. Some of my best sessions have been at 3AM after telling the computer to go fuck itself and banging my keyboard.
This code system (in article) for someone like me is hell - but I like to build stuff. I hate fixing bugs, etc. But in "maintenance mode" or "bug fixing mode" a system like this is kind of necessary.
"The simplest and probably most widespread metric used to measure developers is how many pull requests they’re merging."
I suppose it's good practice to "backup my work" at the end of the day - I mostly don't though. If I need to fine. But I mainly push to a repo when I want to demo live, or working with a dev and we need to share. Big teams with lots of moving pieces, pushing repos each day is necessary I suppose? Or is this just bad codebase architecture? ...Small teams are more effective IMHO on smaller "modular" codebases/microservices/components/modules...etc.
It's also comforting to remember not all managers are so short sighted. There is this purported quote from Henry Ford https://www.goodreads.com/quotes/6872338-henry-ford-s-reacti...
At this point you might as well consider switching careers to product management!
I don't think its unreasonable for somebody to be able to demonstrate they they worked the 8 hours they said they worked. Especially when a lot of the work is just "thinking".
Have you folks never worked with somebody who literally does nothing all day?
Have you folks ever paid programmers out of your own pocket?
I know agile is unpopular these days, but I've always liked daily stand-ups so I can describe what I "thought about" all day. What problems I faced. What was challenging about the design. What I discovered in my research.
Companies do have people who just burn out, get bored, or just stop working. How are you supposed to find those people if nobody ever has anything to show?
Yes, we've all worked with people like that. They are easy to identify, regardless of what kind of metrics they throw out. All you have to do is use your subjective powers of observation, and have the courage to believe this instead of trying to justify it through metrics. If you are not able to do this then no amount of process or fake metrics is going to save your development team.
In particular, if you are measuring the number of hours people work as a way to measure productivity, then you are in deep, deep, deep shit.
Yeah I have worked with someone like that, but as someone who does actual work I don't see why because of that moron I have to document every step I am taking. Feel free to come in once a day and let me describe to you what I am doing, the rest is in the commit messages.
The guy I worked with was thrown out recently. Unless you work in complete isolation your peers know you are not doing your job, and once that pisses them off enough it will be more widely known.
> What’s a more realistic scenario here? Your manager stands up to their entire chain of command...
She should try, at the very least. Otherwise you have a bad manager. Your manager's job is to look out for what's best for the team, not to answer to a chain of command. This isn't the military.
If any employee, at any level, can't have a constructive conversation with the level above about what the level above has gotten wrong, you have a busted company culture.
Remember, you, the IC, are supposed to be the expert at your programming job. Your manager doesn't have that expertise, but she is supposed to be the expert at understanding what you're up to. Her manager doesn't have that expertise, so the second line manager should depend on your manager for that information, rather than dictate down manifestly inadequate productivity measures.
Additionally, if your organization doesn't have the kind of culture where managers do this, then you should get out as soon as you can. It is the kind of place that doesn't value quality because quality is too hard to measure. Start looking for a different place and don't stop looking until you do.
A police officer sees a drunkard under a streetlamp and asks him what is the matter. He says that he dropped his keys, and the officer asks him where he dropped them. He points off to the side and says that he dropped them over there, but "the light is better here".
> because quality is too hard to measure
This is the heart of it. A common business school trope that leaks everywhere is to be data-driven. This is fine up to a point. Once you realize that you can't measure actual quality, and decide to measure something else and call it quality, you are now part of a management structure whose goal is the preservation of the management structure.
Then she will eventually get pushed out. You can't fight the culture of your leadership forever.
> You can't fight the culture of your leadership forever.
Depends where you work. I've been at a big company where the leadership cycled at a pretty regular pace; don't like the current leadership, just wait and see if you like the next set; in the mean time, hope for benign neglect; leadership is busy, maybe they'll just leave you alone. OTOH, I've also worked at companies where the CEO is the founder and still has majority votes --- leadership cycling was a lot less at those places.
>> Your manager's job is to look out for what's best for the team, not to answer to a chain of command. This isn't the military.
Aside from the naïve understanding of military culture, an organization full of managers looking only to promote and protect their teams is equally unhealthy. Dilbert spoke of "battling business units" whereby each team fought against one another to promote themselves. Not good. A manager must represent their team upwards to the higher chain, but must also represents the higher chain downwards. It is always two-way conversation.
> Your manager's job is to look out for what's best for the team, not to answer to a chain of command. This isn't the military.
No, your manager's job is to make their boss look good. This trickles up to making the CEO look good to the board and ultimately the investors/shareholders.
Depends if you work for a shit company or not.
From the comments here, I think some have only _ever_ worked for shit companies. Other kinds of places do exist!
No that's just private equity, and public companies. Real companies, companies that sell stuff or services to others as the way they make money, have to deliver stuff to customers. The whole company has to answer to the customer.
I don't really disagree with anything in this post, but it's a bit sad. I understand the "why" of the scenario, but it will never not be frustrating to me when I have to "prove" that I'm creating value because I didn't tailor my work to optimize for whatever system the company is using.
Like, I just want to solve problems with code, I hate that I also have to constantly advertise how smart and useful I am because managers are so myopic that they can't figure out if I'm valuable.
It brings out the worst in people; you get people holding meetings about stuff that could be summarized in an email in order to give the illusion of working hard. Pages and pages of documents that will never be read are created because if you don't create them then it's hard to say you were doing stuff. Hundreds of tickets pile up in Jira that will never get done because you need to give the appearance that you're actively important in the improvement of the product(s).
I get it, it's the world we live in, but I don't have to like it.
It's not that your manager can't figure out who is valuable. They probably have a good idea about that. What they can't easily do is protect or promote people whose metrics don't fit whatever KPIs that the senior leadership are currently pushing as essential.
I have to get my team to do the things the company expects, even when it's dumb or annoying. I can't get good bonuses for people who aren't visibly hitting the right targets.
Unless your total mission in life is to reform the company (good luck with that), you go with the flow. Having a good rant about it helps sometimes. But managers don't have much power to change the whole system.
Sure, I understand it’s part of the game we have to play, but I don’t have to like it.
It also makes me sad that someone is earnestly and honestly trying to hack through these weeds, when someone with the gift of the gab will sit in that performance review, jazz hands their way through it, and go for a barbecue at the manager’s house that weekend, while having done precisely 22 minutes of arguable work in the last quarter.
I mean, I know. I’ve been that asshole. Useful to still have a paycheck while you’re getting a startup off the ground. I got so much practice at “the dog ate my homework but here’s a fresh coffee” as a kid it was ridiculous.
Absolutely.
I had a job once where my manager and the CEO were both fairly frequent smokers, and so the people at the company that smoked would go outside and join them on their smoke breaks. I noticed that these people were frequently the ones who got bonuses and the benefit of the doubt compared to the people who didn't smoke, I think simply because they had more exposure with the leaders.
I didn't (and don't) smoke, so it was always a bit awkward for me. I suppose I could have just hung out with them as they smoked and I didn't, but I never did that.
Yeah, I literally took up smoking for business. British retail magnates pretty much all chain smoke. Going and hanging out at the smoking area at a trade show was a great way to meet prospects, and more than a few deals were shaken on while we nipped out of a sales meeting for a fag.
Horrible for your health. Great for your career.
This stuff may happen, I can't say it is untrue, but I've never seen a manager terminate a decent to good programmer because they didn't understand their workload.
The companies I've worked for spend a lot of time recruiting talent. If a manager wanted to can someone because they didn't know that fixing bugs takes time, it would be the manager in front of a more senior manager demanding they explain their logic. Also, if you've managed programmers or SW projects for any amount of time, you'd understand why things take time.
Most folks I've seen get terminated is because the company is shrinking, or they are not performing or they are a jerk and/or violating company policies.
My thoughts are do the best work you can, be nice to others and you'll be fine as long as the company is making money. Don't worry about 'metrics', people generally know who's worth keeping based on more than that alone.
> This stuff may happen, I can't say it is untrue, but I've never seen a manager terminate a decent to good programmer because they didn't understand their workload.
This happens all the time. It just doesn't look so obvious.
In practice management will push the developer to communicate and document and justify the work. If the dev complies, they find themselves spending most of their time on the overhead. Welcome to big software enterprises where very little gets done.
If they don't comply, then management will keep adding pressure and eventually get rid of the developer because of "behavioural issues".
I once heard someone say a phrase which feels relevant to this article:
"If you know nothing of what they are doing, you suspect them of doing nothing".
I've used this sentence to catch myself over the years where I've been quick to judge someone as doing nothing at their job or day-to-day, and then used it as motivation to (if possible) learn about what their days actually look like. I'm almost always finding out I just didn't know enough about what they did.
As the article points out, this goes the other way too. It doesn't matter how good you are at your job if nobody at a decision making level understands what you are doing.
Keeping a paper trail of what you've done in the ticket, issues you came across, and questions you've had while working on something, even if you were able to answer them yourself is great advice that really separates junior from senior devs.
I do a lot of documenting but not for the paranoid reasons in the article but to leave breadcrumbs for any person, including myself, who might need to look for information in the future.
I've worked long enough to get absolutely tired of yet-another-archaelogy-trip to figure out business logic, a reason for that weird counter-intuitive implementation, how exactly a bug was detected and fixed, why the architecture looks this way, so on and so forth.
It's one of the most draining and stupidest part of this job.
When I bump into someone's else work who diligently left breadcrumbs scattered around; in commit messages, PR descriptions, comments, history of tickets, etc. I almost literally jump with joy.
It's a gift to the future that I really enjoy paying forward, hoping I can instill this feeling unto someone else, again: including myself.
Nothing makes me more sad than seeing a PR with the default description like 'Closes FOO-123'.
Conversely nothing makes me happier than an informative description especially when it states how the PR was tested. Sometimes I don't even need to look at the code.
Yep, "visibility" and "impact" (oh, how I loathe those words) are everything in a competitive environment or when management is looking to make job cuts. If your manager can't make the case as to why you are more important to the organization than your co-workers, your employment hangs by a thread.
100%. Consider a scenario where someone with too much money accidentally is forced into buying out your company and then they decide to cut 75% of the workforce. At that point it's all metrics, good or not, that decides who stays and who goes.
>Are these tools measuring the “right” thing? It doesn’t matter!
Eh, not always. Sometimes it's truly random. For example, at one of the recent Google layoffs, they fired a guy who was oncall. He just woke up and didn't have access to his email anymore, even though he was supposed to be responsible and react to any issues in some service.
Layoffs and PIPs are very different. The former is random, or at least the decision is made at the top of the organization by someone who probably doesn't know who you are. The latter is about your specific performance.
Yep, same thing happened to us at AWS. Sometimes it’s actually random.
In reality that coworker got fired because he was sending inappropriate DMs to all the young women in the organization.
If only! I’ve been employed here way too long.
> If management is measuring pull request (PR) throughput, is it really so bad that developers start pushing through smaller PRs? God forbid we end up delivering value faster with fewer defects, better testing, and more thorough peer review.
This one bothered me. Because increased pull request (PR) throughput does not, in ANY way, imply "fewer defects, better testing, and more thorough peer review". In fact, it probably implies the reverse; just writing the smallest amount of code you can to get it out the door, then coming back and adding to it later. Edge cases? Next PR. Automated tests? Next PR. Comments? Next PR. Maintainability? Next PR. Taking the time to make sure the feature you're working on makes sense? That's not a PR, skip it.
Measuring PR throughput is the same as measuring lines of code, effectively. Nothing about increasing either one of them implies adding real value.
> If your manager can’t see it, it doesn’t exist when performance review time rolls around.
I've become very jaded around performance reviews. A number of years ago, I worked my butt off putting in insane hours and being extremely productive. I knew that I deserved the highest performance rating possible. And in the review my manager agreed that that was what I deserved, but instead I got a successful rating - completely middle of the road average. I was shocked. My manager informed me that HR specified what percentage of each rating they were allowed to give out and that he had had to give the higher ratings to other employees for various reasons. Ever since then, I've done the bare minimum of work to get by. Why work my butt off to get a successful rating when I can do the bare minimum and get the same rating?
I recently quit a job, for a large number of reasons, but the one most relevant to this post was the topic of my github numbers. My manager gave me a "needs improvement" review, citing my "bad numbers" and comparing them to several of my teammates. Their numbers, to me, were laughably high.
I thought I was doing pretty good on PR reviews. I do one or two a day. I read the description, sometimes more than once. I read through the practical testing steps. I follow them, sometimes with a lot of setup required. I really make sure it does what it's supposed to do. I read the code, line by line. Sometimes before I do the practical testing, sometimes after. But I read through the code, several times. I don't know how you wouldn't. Functions are calling other functions I haven't gotten to yet. So I read through the code multiple times. I don't just try to understand what it does, but why it does what it does. Is there a better way? Is this going to change or impact something else it should or shouldn't? A good code review can easily take an hour or more, in my humble opinion. Two reviews a day on top of all my bs meetings and I still have my own shit to do. How does my teammate have triple my PR reviews for the quarter? Seems crazy.
One day I'm pair programming with one such teammate. We finish the task, I create a PR, write a description etc. I press the ready for review button and start to say, "see you later bla bla" and suddenly there's an approval on the PR. It's been 5 seconds, tops. It's the other teammate with 10x code ninja numbers on the team. I remark that approval was pretty quick. My teammate forces a nervous sounding laugh. They work together ever day and seem pretty close, huh.
Anyway, after that, every morning after I made coffee and opened my laptop I'd spend 10-15 minutes just going down the list of open PRs on the project and approving them. I didn't look at the code or even bother reading the description. I just approved them all. I also started opening PRs for stupid shit like minor typos in comments that I'm quite sure no one even reads.
My next review my manager said I had made some impressive improvements and gave me a "meets expectations".
I'm looking for a job in a different industry now. I'm not out of software development, I just don't think I can work on another e-commerce webapp company run by MBAs again. I think I'd rather be broke.
I think this comes down to a lack of shared understanding on what a PR approval means, it sounds like you didn't believe it meant the same thing as your team did. There's not one standard meaning of the "rubber stamp". It's a culture thing and teams should discuss and eventually agree on what they think it means. Mature teams will have guides, checklists and documented expectations.
It's moderately likely that behind the scenes someone was complaining to your manager that you were blocking their work and that the "metrics" discussion was just a cover for that.
Usually when I review a PR I am just sanity checking the overall approach, figuring out or asking how they tested it, and making sure there's nothing crazy that will cause pain for everyone else later. Detail correctness I don't consider my problem because there's no economic way I can verify it. I can usually approve in minutes and I don't consider it a waste of time, I did the things the process needed of me.
Unless something irreversible is happening (and it should be reviewer's job to be aware of that), the fix for a bad PR is more PRs.
There are projects where almost the only thing that matters is approving quickly because this will let your co-workers get on with their job, this culture tends to evolve in orgs with lots of related repos where you need 5 MRs and pipelines (that flow on to each other) to deploy the tiniest unit change. It's completely dysfunctional but it happens a lot.
I imagine there are places where reviewers are expected to spend an hour "raising the bar" on every PR but I've never worked at one. I'm also not sure if I'd want to.
Note that there's not one thing or process that makes sense, it's very context dependent with lots of exceptions. For example, if someone from a "far away" team is contributing to a particular repo for the first time I will probably reach out to them to see what they're trying to do and review more carefully because they likely have limited context vs a core contributor.
Well then why does the PR template used at the company require manual validation steps on every PR if it's not expected that reviewers do them? Do you really think 5 seconds was enough time to "sanity check" the PR? Do you think 5 seconds was enough time to even click the code tab? Why are two "reviews" even required if the reviewers are actually expected to simply rubber stamp every single PR that comes through?
Edit: "the fix for a bad PR is more PRs" has got the be the worst take I've seen in years.
The review requirement often comes from compliance, many standards require a control to stop developers getting code into production by themselves without anyone else looking at it. Sometimes it's because an engineering manager read a book that said it was "best practice" or because "that's what we did at $lastjob". Sometimes it's because someone set up the SCM to require it and never looked at it again. Maybe it made sense to someone 5 years ago but it doesn't make sense now, for the teams and processes you have. It's worth asking and finding out!
I agree 5 seconds is not enough for even cursory review, why even bother, unless it's a compliance thing. In a functional team the thing you do is raise this in retro and discuss what everyone expects and wants from reviewers.
If your take is that blindly approving merges with 0 care is actually a good thing and that I "lack understanding" then I simply have to disagree lol. Good luck with that.
Sorry that I was not clear, my bad, I did not mean to imply that you personally "lack understanding" in any way.
What I should have written was that there seemed to be a lack of shared understanding among the team, (i.e, agreement) on the value, meaning and expected process for PR reviews.
I don't think there is any particular level of care that makes sense in all cases for PR reviews, I believe it depends on industry, criticality, the particular repo and who is doing what. I think the most important thing is that everyone is on the same page about what's expected.
I've had great success with gitlab and it's issue + mr (they use "merge requests" which tbh feels more appropriate) tracker. I make an issue ticket, dump all symptoms, logs, relevant configs, whatever into it. Then I make the MR, and put all my fix stuff in there. I like the separation of what the issue was vs what the fix was, while still keeping them linked. Really helps when somebody else does the other half.
ETA: none of this is as helpful as having my team and higher ups understand and appreciate what I do, though. That's step 1. Or step 0 if you can feel that out in the interview.
Put if your MR is just one line of code and it took you two weeks, you still have the same problem.
Agreed. That's why the documentation is important. If the issue ticket says "I saw this but once. It took 2 days of reproducing and it could only be done if the moon was in a waning phase while 3 dogs bathed simultaneously" and "this is the log dump. You can see on line 3453 that we segfault" etc, it shows what you've been doing.
The way I felt the article should be interpreted is that yes, if after 2 weeks you have a 1 line change, that's going to get you fired. And debatably it should, given that it'll likely take somebody else another 2 weeks to fix a similar problem. Why would a manager want to pay 2 weeks salary for (what we call, unsure if commonly used) "tribal knowledge"? At least do a post-mortem/lessons-learnt
Gitlab and its ability to link together issues, MRs, branches and commits is a lifesaver.
Oh yeah the branches too. It's made it super easy for me to ticket the issue, maybe the MR + branch in one click, and add it as a worktree. Honestly worktrees have saved my multitasking. I know Jira/Bitbucket do similar, but that's not what I primarily use.
> If management is measuring pull request (PR) throughput, is it really so bad that developers start pushing through smaller PRs?
So, just the previous week I've made 5 small PRs, all of them working on the same certain "area" of the code base but different pieces of it. Two of those PRs touched almost every single corner of that "area" (differently structured error reporting and differently formatted logging) another one had a rather sizeable refactoring and code movements between three major files of that code area, and as for the two remaining ones, one absolutely depended on the other but could not be done in the same PR because of how the JIRA issues were structured (i.e. "PROJ-9004: Make it do foo", "PROJ-9005: While foo from PROJ-9004 is happening, make it also do bar").
I've also made a decision to not order those PRs sequentially (i.e., base the next PR on a previous PR), and instead branched each PR from the dev trunk and went to work on them. As a result, I've increased the work I had to do approximately by 50% because of the merge conflicts I had to resolve. The reviews combined took about twice as much time as a single big review of all five changes in one PR would've probably taken. The QA took about five times as long since QA did full regression of that code area 5 times instead of 1 time; they've also almost missed an error in the 4th pull request because of all the repetitiveness.
All in all, 10/10, recommend it if you need your coworkers to get lost in the maze of similarly-themed little branches, all alike.
reminds me of this:
https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
so we are the losers.. ah. Fine.
Do those things if your current job require them, but at the same time have a plan to leave this hellhole as soon as possible. Those kind of places value more effort, or worse, the appearance of effort than the results. So, act accordingly, but leave as soon as you can.
>They have tools that will suck up data from literally every possible source available. And these tools are getting better every year. Tools like Jellyfish, CodeClimate, Quantive, and if your organization is old and rich enough, plenty of homegrown stuff. If you’re unfortunate enough to live in the United States, they can legally install a keylogger on your laptop.
This is why my next project is a programmable HID bluetooth device that simulates key strokes and mouse movement. Imagine hackertyper.com but from a device instead. Because your corporate surveillance metrics are bad and you should feel bad ;)
Kind of sad that paperwork is more important than work. In my experience I don't want to be in companies that have this culture, and I take my contributions where I don't have to constantly prove myself.
In other words, if you are not excited to work with me, I am not working for you. Too much feudalism mindset in especially the US workforce is hampering wide-scale productivity.
If your work environment is not win-win and you're managing optics to avoid getting fired, just go where your coding talents are valued & be a happy person instead.
> Kind of sad that paperwork is more important than work. In my experience I don't want to be in companies that have this culture, and I take my contributions where I don't have to constantly prove myself.
Welcome to Bullshit Jobs. People are being forced to be stressed about absolute lunacy.
Blogging and writing lots of white papers has become one of my favorite techniques for this in IT. Pretty much anytime something really interesting happens, I'll spend some time carefully writing up a detailed explanation. I often find myself surprised by my own findings when I re-read them months later.
There's a lot to be sad and mad about in this, but keeping an engineering journal or logbook is a great idea.
> Your manager...“I don’t [know how it goes]. I went to business school.”
There's the problem.
Organizations whose leaders aren't able to discern your actual value are going to be miserable places to work. You play their games or baffle them with BS. But you don't get to attain any sort of authentic actualization.
...
Take my pessimistic commentary with a grain of salt. I'm job searching at the moment for a software manager role and the opportunity landscape is a wasteland of b2b insurance widget companies, usury companies, and AI dead-ends. If you want to build things that help real people, you may have to DIY.
If someone told me "I don't know. I went to business school", I'd then ask "So why are you managing programmers, shouldn't you be managing business people?"
But all joking aside, I think there are few MBAs so dense as the one portrayed in this article. Sadly, I'll probably be proven wrong...
Somehow software engineers can be as dense as the MBA in the example.
I had a manager who used to be a dev. He remarked that a certain teammate is really productive and gets so much done. I asked how he knew and he said that when the teammate is on call he is able to close a large number of tickets.
I showed him that the teammate just closed all the tickets as “self resolved” or “can’t reproduce”.
>>“Well I fixed that showstopper bug! And everyone agreed it had a big impact.”
>>“It looks like the fix was just one line of code.”
>>“Yeah but it took me two days to find that one line haha, you know how it goes.”
>>“I don’t. I went to business school.”
Was this article written by a LLM? Coze that's the most made-up, cliché, unrealistic, middle school parody-level perception of how businesses operate.
Any reasonably large and old company with a software base will have a god-awful overengineered incomprehensible duct-tape wrapped ball of mud that needs constant pampering and costly maintenance. With most task being very much "find the needle in the haystack" type, with the needle being that "one line" indeed but the problem in finding it being, obviously, the haystack. And this "needle finding" being that one thing that totally and definitely all this AI hype can't do shit about. Literally nothing, all those 700 billions burned into LLM training are absolutely orthogonal and useless with respect to the real problem maintenance and development of legacy software (that is most software) poses.
Hum... Yeah, it's a parody.
But then you already expended a huge paragraph explaining how it's realistic. So I don't understand your complaint.
Create a paper trail. Crank out tickets. Document everything. Hit the numbers.
No.
Add value. It's not your job to quantify it. It's not your job to create an understanding of what you do.
If your organization or your manager specifically does not recognize your contributions, be happy to move on.
If you get feedback that says "we recognize your value, but we really need x" that's reprioritization. Respond appropriately. If documenting your value in that way prevents you from actually being valuable, be vocal about it. If it's just a pain and you can still do your job, then suck up the pain like everybody else.
I've been in large engineering organizations. They want to quantify everyones value so that there's "fairness". BS. There is no large scale way to determine of a software engineer is good at his job or productive. Yes, some people have more opportunities to affect the bottom line than others. Yes, some people have easily quantifiable work. That's how the world works.
Have they figured out a way to recognize and effectively incentivize good teachers? Not in my 51 years.
Have they figured out a way to recognize and effectively incentivize good CEOs? Nope.
What makes you think that we should be that easy to stack together and figure out?
I'm senior. I'm experienced. I'm valuable. I'm not always right, and I am not always valuable. In the end, I've had a good and healthy career focusing on the things I'm good at and the things I care about while letting other people figure out if I'm worth what I cost to keep around. Some of those people made good decisions and some bad ones. I still moved forward and my kids have always had food on the table. I say that's enough.
the most unproductive places I have worked - ran according to what OP says and some of the comments etc. things that should take a week took 6 months due to bureacracy and everyone covering their ass and documenting details that don't matter. because after all - they have to account for your time.
the most productive n best place I worked at - whether the work was delivered after 5pm or at 11pm - as long as it was quality and delivered that's all that mattered.
thing is most software engineers don't think like "business-men" and just as Jay-z said "i'm a `business` man" not a "business-man". Be a business, then "business-man" then lastly a jira ticket pusher. Jira ticket pushers lives are miserable -- you get hazed over leetcode, you have to be pretend-nice to your fellow jira ticket pushers because of 360-review etc.
learn to look at other industries and see if they play those stupid games.
DORA’s such a cult.
In other news, I’ve had pretty good luck when trying to build culture by getting people to measure both the act of practising the behaviours and the overall expected outcomes, but not setting specific targets on the teams. Measuring the outcomes for individual teams leads to “checklisting” rather than behavioural change.
if only there were some type of way to operate a tech business that didn’t generate pathological incentives
oh well, back to my scaled agile workflow grooming planning meeting grooming meeting planning meeting
You don't get pulled into a meeting like that unless other devs were already pointing it out.
My experience has been a little different. Usually you have regular one-on-ones with your manager where you discuss career things, including what you've been working on lately. From being in the manager shoes myself, I do this so that you and I are more ready to advocate for you when it comes to actual performance review time.
> You don't get pulled into a meeting like that unless other devs were already pointing it out.
Aka backstabbing?
Idiots who mismanage should be fired instead of people who provide the value.
Aaand, there are companies where it happens
> “Yeah but it took me two days to find that one line haha, you know how it goes.”
> “I don’t. I went to business school.”
The conversation should end right here.
They don't know what they are managing, why fixing things is unpredictable, and worst of all - they are communicating AFTER the fact, one month later - which is too late.
The manager needs to be fired for incompetence and incapability. But this is not how tech companies work - leading to all the management hate.
This is dumb.
We've gone from "You don't get promoted if you don't show clear visibility for the things that you do" to "You can get fired for not showing clear visibility for the things that you do".
The first is true. The latter isn't.
There are dystopian black swan events like the richest person in the world going on a ketamine binge and buying your company and dragging everyone into a meeting room with printouts of examples of your code.
Unless you're involved in one of those, noone gets fired for doing a lot of things but not tracking them enough in JIRA to cover your notes.
Most teams know who on their team gets shit done and who doesn't. They also know the ones who get things done without a clear track record of it. They are asked to help with every problem, and are constantly too busy to get their own stuff done because they're helping everyone else with theirs. Yes, they struggle to get promoted, but they certainly don't get fired.
The people who get fired are the ones who THINK they're in that group, but they're talkers, not do'ers. They get fired and everyone shrugs and goes "oh well, anyway."
Then they go and write blog posts like this to help precisely the wrong type of person that needs this advice - cargo culting impact. Becoming allegiant to process for the sake of visibility.
It'll certainly lead to more clutter and confusion in the world and in the tracking systems.
Might as well write blog posts about how to pad your line counts in your pull requests so that people looking at your Github graph at performance review time think you did more than you did.
You're the perfect example of "holds an irrationally strong opinion about something they know nothing about."