That's one possible union architecture, sure, but you're missing the forest for the trees. A union offers job security to reduce the risk of "managing up."
It's the one used by all the major ones: airlines, auto manufacturers, and teachers. What institution do you know of that has a greater emphasis on measuring performance?
I'm sure most unions would love performance based pay where union reps decide what constitutes good performance. For some mysterious reason management is as keen on unions exercising their judgement as unions are on management deciding.
Where unions agree policies that treat members as interchangeable (e.g. age based pay) it is usually as a result of a compromise brooked with management who would love to have the latitude to give pay raises to scabs, kiss asses and spies.
That's not generally how it works in professional sports with player unions. Nor does it work that way in the film and television industries where there are unions representing writers, directors, actors, etc...
The shape of the union is whatever the membership wants it to have.
Both of those examples have weaker unions that play less of a role. Also the poster above suggested that the union as opposed to the management could measure performance. That doesn't happen in sports or TV.
Really? From my manager and up at least 4 levels has been unchanged for at least 8 years. Titles changed some, but the same people are in the same effective roles.
How would coming up with good metrics for "management" be any easier than coming up with good metrics for "programming"?
At least programming has some verifiable realities that can be witnessed objectively by multiple observers. Not that such things are often used on "metrics", but they could be.
The quality of someone's management is hard to assess from outside, much less objectively verify. Has your manager increased or decreased your productivity today? Was it necessary that they do so for a larger goal you're not considering? Were they just power tripping?
"Hey, boss who can fire me, I just thought you should know that we on the team have started keeping metrics. I want you to know that your 'times you made the only girl on the team uncomfortable with a sexist joke' metric is unusually high this month, and your 'unblocked the team by speeding up an external request' metric is 0 for this month, down from 3 times last month"
Let me know if you find any downsides.
Anyway, management will of course argue that developers under them are incapable of seeing everything management does. After all, management's job is to shield developers from other managers, so if the developers think all the managers at the company are worthless, that's actually a sign of how well management did their job of shielding each other's teams from each other.
We all feel like management contributes nothing, right? But they seem to always be around successful companies. I dunno, correlation isn’t causation, but I think there must be something there.
Weirdly enough, many unsuccessful companies I know of had management too. Correlation isn't causation, but maybe there's something there.
There are also plenty of successful companies and projects without management too. Basically every 1-to-5ish-man consulting shop has zero managers and some of those do wildly well. Some of the best indie games, produced by teams of 3 or 4, had zero dedicated management. Most open source projects have effectively 0 management.
Valve, famously, kept a flat organizational structure for a long time, and certainly was somewhat successful.
AI is actually now shaping up to replace these jobs much more simply than blue collar work.
So, yes absolutely, administrative work now can finally be replaced, and we can free up all the tormented souls in these managerial positions to do something more meaningful with their lives.
In many workplaces middle management has already been automated. Algorithms manage Uber drivers. Algorithms manage Amazon warehouse employees.
These companies are even more stratified than before with the lumpenproletariat doing human-mechanized tasks while executives program their lives using software we write in exchange for the unbridled luxuries like the chance to own a roof over our head one day.
>Anyway, management will of course argue that developers under them are incapable of seeing everything management does.
What a coincidence! Thats one of the first thoughts that crept into my head when code metrics started being used on me.
This "voyage of discovery" you've alluded to is exactly what I meant by no downsides.
If managers feels threatened by being measured by their employees after their employees start measuring them, well, that's also an interesting reflection is it not?
Management also have their own metrics, measured by even higher management further up the chain. Even if there is a manager or director that I really liked and would like to keep, they have to answer to the metrics of their VPs and SVPs above. It's metrics all the way up.
People at the top of the hierarchy probably do care about people at the bottom, but it's difficult to care about a large number of people as individuals, so they resort to metrics that probably models what's going on. Unfortunately, the metrics don't always work.
Instead of measuring and gaming numerical metrics, enforcing a particular culture might be a better way to go:
Reminds me of an anecdote about Bell Labs. Someone calculated who the most productive employees were (based on things like patents received), and found that many of them would eat lunch with the same person. That person wasn't individually very productive, but he would always ask thoughtful, compelling questions that in turn made his coworkers measurably more productive.
It might be from the great book The Idea Factory by Jon Gertner (p 135).
'In the midst of Shannon’s career, some lawyers in the patent department at Bell Labs decided to study whether there was an organizing principle that could explain why certain individuals at the Labs were more productive than others. They discerned only one common thread: Workers with the most patents often shared lunch or breakfast with a Bell Labs electrical engineer named Harry Nyquist. It wasn’t the case that Nyquist gave them specific ideas. Rather, as one scientist recalled, “he drew people out, got them thinking.” More than anything, Nyquist asked good questions.'
The most impressive thing about this story is that they figured out the answer. They did the research, and nailed down that it was Nyquist who was was the productivity booster. It’s the exact opposite of the OP’s story, where management tried to fire the Nyquist-equivalent.
They found an answer that felt right to them. The reseachers weren't blinded to the context they were working in, and their hypothesis is essentially unfalsifiable so I would take it with a grain of salt.
Honestly, I'm kind of skeptical of the answer. I'm not saying that talking with Nyquist wouldn't be useful, probably it was, but what's stopping a dozen other things at least that useful from being part of the answer?
Harry Nyquist isn't exactly an unknown engineer who doesn't have his own achievements, though - not sure why people are saying he would be fired in a modern company!
I agree with you 100%. Management does not have an eye for software that is easy to maintain and continue to make money on 5 or 10 years down the line. Most management is thinking short term, how do I get money in MY pocket right NOW. Who cares how the business does in the long term, they'll jump ship and move on. It is the engineering that often makes a difference for long lived companies, it's just that usually the engineers and/or management isn't around long enough to reap the rewards. I try to balance engineering with product cost (I'm lucky enough where I can see the "numbers"). I try to give more to the clients that pay more, or at least create something that I can reuse in the future, while making sure what I deliver is stable and not a big ball of spaghetti to make the next developer/engineer cry at night.
> ... 5 or 10 years down the line. Most management is thinking short term,
Woe is us. Five or ten years is not considered short term
> . I try to give more to the clients that pay more, or at least create something that I can reuse in the future, while making sure what I deliver is stable and not a big ball of spaghetti to make the next developer/engineer cry at night.
I am not sure about the "...who pay more". As I am currently woefully underpaid I am more sympathetic to that view than once I was, but, I still view myself as a professional, and I act with professional ethics.
Partly that means speaking up when I see a project going near the rocks. I do not make too much fuss, but I do say it out loud.
That has cost me plenty. Our industry is full of people who are very good at one thing or another, but do not know their limits.
Part of my "being professional" is knowing my own limits.
I am in 100% agreement and the same thinking as you are. I never take the shortcut route unless it is absolutely warranted, such as a solution I know is meant to last only a few months. I have been very loud, and have effected quite a bit of change over my years, if only in a way that allows my boss to believe that I will no longer be a part of his operation if he restricts my freedom and personal ethics. I am highly underpaid, but I make sure to take that out in personal freedoms where it is worth it to me. I no longer answer phone calls or texts after hours unless they are going to directly damage the business, and my ability to continue having a place of employment. I take regular vacations, and mental health days, sometimes just to spend time with my son (went through a divorce where I still can't tell how badly it affected my son, although luckily went through a moderator rather than the attorneys/courts to settle things).
It is important to know what you can and can't get away with, and my clients don't pay the cost of the business I'm employed by making bad decisions. Where I am able to, I strive to provide a product that is better than the average, in the hopes that I've developed a solution that can possibly benefit the company or myself in the future in regards to software quality or speed (along with stability) of deployment.
"In an effort to avoid naming everything after Euler, some discoveries and theorems are attributed to the first person to have proved them _after_ Euler."
That kind of people was somehow mentioned in Peopleware. A group of people is a subtle structure, and good team spirit, good questions can improve things "invisibly".
I'm sure your bubble is a wonderful place for you to exist. I can't speak for anyone who has to interact with you, but inside of it, I'm sure it's great.
It's basically a trope on this site for everyone to imply that everyone who doesn't have their fingers in code 8+ hours a day has a so-called "bullshit job," as if developers don't work for businesses which have to earn money, so forgive my skepticism.
It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). Hence the Problem Domain and technologies used in the Solution Domain are what matter and everything else is ancillary. The Processes/Methodologies used are only useful in as much as they help us understand the problem domain better and map it to a specific solution. Thus the application of the former is informed by knowledge of the latter and cannot exist by itself. Hence the reason we have so many types/variations of Processes/Methodologies; there are some common principles but will always need to be adapted/customized to the problem and tools at hand.
Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.
There is a difference between "understanding the work" and "knowing how to do the work".
I've had multiple Producers who "understand the work" of creating mobile games as a whole and understand how the team needs to work and interact to produce a result on time.
None of them could code a mobile game to save their life.
What your example is talking is a situation where a fresh off the press MBA is shoved in to a very specific field and they start just doing pure numbers and Excel management out of a management book without knowing how that specific industry operates.
Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
>There is a difference between "understanding the work" and "knowing how to do the work".
True. However, the relationship between them need not be a "Total Function" but definitely needs to be a "Partial Function" to a certain degree. You cannot be completely divorced from the "How" and hope to have a good "understanding" of the system.
>Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
This is precisely the point; domain/technical knowledge is needed to effectively Manage a project. This is independent of knowledge of techniques of Management.
The problem today is that entire industries have been created out of thin air which posit that the latter is sufficient if one follows a certain process/methodology which is patently absurd.
No, I think at least in large part, you missed the point.
> It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever).
As I understood _Bullshit Jobs,_ "adding tangible value" to some business that doesn't actually add anything of actual (non-monetary) value to the world is bullshit. There are whole industries that make billions of dollars, but everyone who works in them is still doing a bullshit job. (I often think I do.)
You are talking about the meaningfulness/meaninglessness of the Business/Technology Objective itself. That aspect is certainly relevant and can be Bullshit (eg. companies selling Scrum master/Agile coach certifications :-) but in the context of this thread we are talking about the bullshit jobs created within an organization in the bureaucratic/administrative/managerial/leadership "roles". This is what is more insidious and needs to be rebelled against.
... as he describes, five types of entirely pointless jobs: ... 5. Taskmasters, who create extra work for those who do not need it, e.g., middle management, leadership professionals.
In companies, he concludes that the rise of service sector jobs owes less to economic need than to "managerial feudalism", in which employers need underlings in order to feel important and maintain competitive status and power.
Graeber also formulated the concept of bullshitization, where previously meaningful work turns into a bullshit job through corporatization, marketization or managerialism.
The best amplifier I've met was hired as a junior coder to my team and was paired with a couple of 10x coders on a project with a client who was "hands-on" and loved to micro-manage, having been a software developer themselves a long time ago.
The Amplifier's coding output wasn't that good, but the team as a whole was doing better than before so I investigated.
Turns out the 10x guys weren't that keen on communicating with ... well anyone outside of the team, much less with non-technical clients (or technical clients who loved micromanage). Both were your stereotypical cold pizza and warm cola coders with limited social skills. They could kinda sorta manage the meetings and emails directly from customers but didn't exactly relish it.
The junior hire was more like a 0.5x coder, but had ample social and organisation skills and worked extremely well as a liaison between the team and any external contacts they needed, taking over most "useless" meetings with the product owner and customer.
The junior coder ended up receiving some training and was "promoted" to a Scrum Master/Producer/Project Manager (the exact title escapes me) for the team. Everyone was happy and productive.
Your "Amplifier" is more like what is known as a "Field Applications Engineer" in the Embedded industry i.e. somebody with enough Domain/Technical/Marketing/Sales skills fulfilling a tangible need for the Business. They are more a "Business Process Optimizer" than a "People Amplifier"(a term i made up :-) who i define as somebody who can spark creativity/insights/viewpoints etc. which push others forward in their problem-solving endeavours. It is not merely removing hurdles/book-keeping/time management/liaisoning but an active role involving discussions/brainstorming/idea generation. This cannot be done without bringing some expertise to the table relevant to the problem at hand.
I don't know about you, but I don't tend to have breakfast and lunch over Zoom.
While I did go out to lunch with coworkers more often while working in the office it was almost exclusively with direct teammates, and other groups I occasionally saw where also on the same team.
Now that I'm fully remote, I will typically do a few "hacking sessions" over Zoom every week. Its much easier and more comfortable than standing over their shoulder in tiny cubes we used to have.
That said, especially now that i am fully remote, I've been trying and mostly failing to get developers especially across teams to talk and collaborate more. But its not too suprising: I was recently in a call and I was introduced to another developer who I replied, "Yeah, I know you. I was in the cube next to you for 2 years and on your team for 6 months."
Remote creates some new challenges, but its a culture thing, not a technology thing.
You know, after I wrote this I got to thinking, "Why don't I have have more social Zoom calls?"
The answer is that I never was good at social things like inviting people to coffee.
But it doesn't help that we're taught to "protect" our time and avoid unnecessary calls and meetings. Presumably so we can write more lines of code, close more tickets, or earn more points like the story and other anecdotes here.
I think I may try something new in my calendar. Worst case I'll end up sitting in front of my computer alone with a block for the next hour and nothing to do but work on all those things I need to do anyways.
My thoughts were that neither of them should have been surprised by the rating. When a rating comes in substantially different than expected, it's usually because A) They aren't talking during the week B) The manager is weak and doesn't want to issue corrections when they meet C) The employee isn't asking "How am I doing?" during their meetings D) It's being directed from upper management for obscure reasons.
I dislike the just-so aspect of these sort of stories. I'd expect exceptional programmers to do unusually well on most metrics.
But that is balanced by the threat of people trying to use metrics to measure developer productivity. It doesn't seem to be possible, any metric falls apart. If people are focusing on a metric, the greats aren't going to be leading any more. It'll be some junior who has misunderstood the system and has accidentally trained themselves to game metrics.
Metrics do not drive good software. Repeatable processes love metrics. Repeatable software suggests bad development practices because that is a big hint of a library or bigger opportunity that nobody on the ground properly identified.
> I'd expect exceptional programmers to do unusually well on most metrics.
...when they're actually hands-on-keyboard writing software. The best programmers I know write as little code as possible.
Product team: Hmm, we need to do a thing that looks very complex and difficult.
Senior dev: I'll start making a project plan and story breakdown.
Very senior dev: That sounds like a special case of a thing we already have. That should take about an hour.
Of course that's a generalization, but I think the trend holds. The most illustrative metric for the best engineers wouldn't be "lines written" but "lines avoided".
In my experience, the best programmers write the least amount of code they can get away with.
I don’t mean they use the latest fashion library, I mean the amount of code they type is less simply because they understand the problem and know how to write a minimal solution.
This makes their code easy to read and therefore easier to debug.
It’s worth noting that the less you type, the fewer bugs you’ll create.
To be fair, this is often due to the coder having significant experience.
Why do you say red flag? It is an exaggeration, of course, nothing is purely 1 hour. Rather it is 1 hour work in flow state, which is about 2 pomodoros, which is about 6 bulletpoints, which is about 1/4 of a day’s programming effort. Just about right for a 1 point card by a senior who only sit down to code when they kinda exactly know what to write
Talking about flow state and estimates? The red flag just gets bigger. You are asking me to show you that Santa is not real.
A "very senior dev" will not be handing out "1 hour" estimates to a product team. An hour of what? Billable hours? Wall-clock time? It's just not the right framing. You will notice a good senior dev will be incredibly cautious about any commitment and not hand out "ego estimates" like one hour. They will make commitments that they can keep and it will be terms of releases.
They will have experienced a decade of "one hour jobs" that have exploded so they know that even the error bars on a slam dunk 1 hour of butt-in-seat time means it's not a 1 hour estimate. An hour of butt-in-seat coding time is not a 1 hour of employee time - they've got that training course, those interviews, they need to support that thing, oh the presentation, the intern to look after. That feature you are copying? What is it copy-paste or some refactor generalisation? Measure that shit in weeks. Oh and there are 6 feature branches overlapping that area already. You also have a policy to improve the tech debt of this crusty code. There is also the documentation, training material, translations, the test suite, code review, the issue tracker... But hey, you can do it, you are x10, you boot up your machine and... your IDE is crashing because of some security update. Doesn't count in that one hour eh?!
That's not even the main issue, odds are the first over the shoulder demo of this new feature will be just the start of eliciting the real requirements.
If I say 1 hour, I mean that I know exactly which knob needs to be twiddled, perhaps because I wrote it in the first place, and that there'll be a pull request ready for review an hour from now.
That's clearly not always possible. Sometimes it is. If I say that it is, then I can deliver it.
Scale ruins everything but that's where you will find "very senior devs".
> Sometimes it is.
What's the worst case of the other times? These "one hour" estimates are the golden path, nothing goes wrong, minimum. It's not the average of horror shows or an amortisation all the related support work required to sustain efficient development over time. They are often too coding-focused and ignore the level of interpersonal work to agree and sign off features or to change code in collaboration with others. Talking through a demo can take more time than the code.
"Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. ... Bill Atkinson ... thought that lines of code was a silly measure of software productivity. ... [He] made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code. ... when it was time to fill out the management form ... he thought about it for a second, and then wrote in the number: -2000. ... after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied."
Well, I like the story here, but it's kinda against a bit of a strawman. Don't get me wrong, I'm not losing the overall point of the piece, a point I agree with, but that said a metrics focussed manager could have simply added an "adjunct" label to the stories and had this "worst programmer" add themselves to stories as the non-lead developer.
Ultimately the best way of measuring programmer productivity is by the assessments of the programmers on the team. This isn't as easy as it seems. For example, I once worked on a team where the best Heroku guy just had the absolute wrong idea about "easily understandable python code" since he would prefer to raise and catch an exception instead of rely on a built-in to test attribute existence or type compatibility. But nobody could get around large scale Heroku deployments like this guy. The juniors understand this nuance less well than seniors do, but even so, it does sorta come out in the wash. Your team does know its best people and they're usually happy to say it in a private one on one.
I believe that’s the conventional approach in Python, though? It is a duck-typing language, try-except is a legitimate way of seen if an operator works on an object, and objects should do sensible things with operators.
The funny example is that the hasattr built-in just tries to getattr, and then catches the exception to tell if it has the attribute.
> Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C.
If you are calling something immediately, a try-except is ok. If you are calling with a try-except just to simulate hasattr or getattr then why do we have the built-ins in the first place?
“Just try and then handle the exception” is a pretty weird paradigm for this sort of thing, to those of us who come from more typical languages. So I suspect they just included hasattr to make us more comfortable.
It's not about incompatibility it's about safety. You drive with air bags or you don't, those two concepts are NOT about incompatibility. It doesn't even make sense.
If there are situations where you have no choice but to drive without airbags, those are holes in safety.
Essentially if you have to have runtime checks to prevent the program from full on crashing those are holes. Not everything is checkable with static checks but the way to go is to move as much of your code away from runtime checks as much as possible.
Not sure I understand your point, there will always be runtime checks in any non-trivial application. Typically these will be for things outside of the code, for example: network status, file access, user input, external input (think JSON parsing), hardware requirements, etc
So for opening a file for example, using try/except instead of checking if the file exist and is readable first.
Both achieve the same results but the first is more "pythonic".
My point is that this way of writing code is not at all incompatible with using a type checker for said code.
>My point is that this way of writing code is not at all incompatible with using a type checker for said code.
I'm saying "incompatible" isn't even a relevant concept here. Here's an analogy:
You're telling me that running with shoes is compatible with running without shoes thus I can run with one shoe on one foot and the other foot is barefoot.
The goal is to objectively put shoes on both feet. Sometimes you're missing a shoe so you have no choice. But this has nothing to do with "compatibility" it's a completely different thing.
We are getting a bit into pedantic territory here, but THAT was my point and I am simply clarifying it because you MISSED the point.
Exceptions are for exceptional circumstances. An object being a certain type is not an exceptional circumstance, not even in a dynamic language. You should never be surprised by the type of an object unless your program has serious design flaws.
The fact that the language doesn't have your back means you need to be more careful about types, not less. The type of the arguments is a function precondition. It's the callee's responsibility to document preconditions and ideally recover cleanly from a violation, but the caller's responsibility to ensure preconditions are met. Illegal states should be caught early, not allowed to percolate until an exception is thrown.
I don't much care if what I just wrote is "Pythonic" or not. I don't think too much careful design up front is responsible for every Python codebase I've ever seen reading like Finnegan's Wake.
You aren’t required to like the conventional way they do things in Python.
I dunno. I don’t love Python for big projects either. If we want to go around and tell all the people using this very popular language to stop shipping their successful products because they look messy to us, I’ll happily take the second shift (after you), haha.
So I used to kind of think like you, but I think that's just not a practical approach. Yes, you could alter the system in this 1 exact situation if you know exactly what to change, but there will be dozens of other failure modes too (engineer releases code that breaks in 2 months, engineer deliberately mis-estimates story points, engineer doesn't comment their code so that nobody else on team can do certain work, etc)
So if you have a manager who is a dialed-in coder who's going to keep updating the jira-point formula based on spending more than 1 hour a day reading code, and keep tuning it around the ever-more creative loopholes engineers employ, then yes, you may end up with a workable system. But never yet in my long career have I seen that.
No, no, you misunderstand. I agree with the point. I just think it was made against a strawman and could have been made even stronger. I'm not for metrics on stories to award productivity points. I'm for one-on-ones and success-as-a-team evaluations.
> a metrics focussed manager could have simply added an "adjunct" label to the stories and had this "worst programmer" add themselves to stories as the non-lead developer.
The story includes a part where they dropped the crappy metric and changed to a better one.
<Ultimately the best way of measuring programmer productivity is by the assessments of the programmers on the team. >
Maybe ... Productivity itself is difficult to define. Different people will value aspects of the work differently
At one Internet Advertising company I worked for, the founder had written most of the original code. Written in the late 1990s, it was Perl, JavaScript, HTML, and SQL jumbled together. Completely ignoring the notion of 'separation of concerns'. Huge amount of code duplication. Source code control? Phhht! Nary a test in sight. Ran programs as root to work around permission problems. Self modifying code ... you betcha. He worked right on the production servers. He could and would push out a feature the same day a customer asked for it. VERY quick to make the customers happy. The company was being bought out at the time I came on board. Pocketed his millions, headed down the road, yay for him.
My own take is that the company would never have 'made it', if a software team had been hired to 'do it properly'.
After his departure, as we rewrote our code base to 'professional' standards, much time was spent refactoring that produced few or no new features. How productive was that? A very complex question.
As a digression, I sometimes found his original code easier to maintain that the stuff done 'the right way' because there WAS no 'separation of concerns'. I didn't have to hunt in a different part of the source tree for where something was done. It was all 'right there'. YMMV.
In the end, 'productivity' is way more subjective that we'd like.
> I didn't have to hunt in a different part of the source tree for where something was done. It was all 'right there'. YMMV.
This is my take too as I have gained experience. The way I did code from the get go, was the overall best way. Long function that did the stuff one thing at a time. Like no functions called from different parts of the call tree. I breeze to debug and understand or modify.
LOL. Yup. And I've been in a company that had a product like that. One man, one file, one function. Scads of GOTOs. It was a state machine, managing ports on a terminal-to-ethernet box circa 1987. Oh my.
> I explained all this to the manager and invited him to come by and observe us working from time to time. Whenever he popped by, he would see Tim sitting with someone different, working on “their” thing, and you could be sure that the quality of that thing would be significantly better, and the time to value significantly lower—yes, you can have better and faster and cheaper, it just takes discipline—than when Tim wasn’t pairing with people.
BREAKING NEWS: Pair programming improves software quality, more at 5!
Extensive pair programming can also be massively draining and burnout inducing for certain types of people. I hate it when companies mandate pairing. Some people's brains just don't work effectively in that type of environment.
Mandating it is stupid, it obviously depends on the team, task and person.
But you can't deny that it's an amazing tool to open silos in terms of knowledge.
I wish people would be more open to it, because I've never been able to get someone up to speed faster with a tool or codebase, than with pair programming. And vice versa too. If you're the person that knows less about the topic, pair programming with a senior is like a one on one tutoring session with a really skilled instructor. It's worth the time in gold imo.
"Didn't happen to me anecdotally so must be fake news" is not a compelling argument.
Also to say it couldn't happen at tech companies is pretty bold. There's nothing special about tech companies. They can hire incompetent managers just as well as other companies.
It sucks being that person today because everything is about optics and that person will get purged. I know from experience.
Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently write 5000+ lines per code per week, regardless of how many features they actually ship and how many bugs they introduce.
As a team lead and engineer who has managed some complex projects, the idea of someone writing over 2000 lines of code per week terrifies me... That's over 100K lines of code a year. Think of the unnecessary complexity. There is a very good chance that the same feature set could have been implemented with just 10K lines of code, less buggy and in half the time though that would only amount to 380 lines of code per week! Management won't like that.
I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code.
Because it's a bogus argument. The productive person doesn't need a paper weight at lunch to act as a shower thought generator. Management can get it wrong sometimes, but in broad strokes, they're right.
It's tough, but what I've seen is low performers weigh the team down. They constantly ask for the high performer's time, and if we give them bug tickets, new feature work, they constantly stumble and always report status as blocked. They don't add value. They can't get to the finish line with anything. It's not a kind thing to point out, but trying to angle it as "oh there's this other benefit you're just not seeing" is trying to work around the fact they can't competently fulfill the job function after exhausting all of our options (training, pair programming, etc). They might be friendly people, but the social boosts don't counteract the losses incurred, it's still a net loss.
You've turned the story round from "Tim MacKinnon is a good programmer and asset to the team which the simple metrics were not tracking" into the strawman "defend people who cant do their jobs and are not an asset to the team by claiming that they are nice people".
Because lins of code churned out is not and has never been a good measure of productivity.
That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem.
Which is basically the entire point of the article.
It's more about measuring outcomes. We have a goal, did we meet the goal. There are many paths to the goal, so measuring things like lines of code is incorrect. But so is measuring Bob's ability to ask Alice a good question. Management can't, at scale, consider such factors. We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways. Performance reviews would become even more subjective if we had to place a value on the impact of asking questions. All forms of measurement are flawed, so I stick with outcomes.
> Management can't, at scale, consider such factors.
Why not? Peer feedback is a prime component of most performance/rewards discussions at companies. Work outside of points is certainly not a new concept. A manager's job is to distill this information amongst others to their own management chain at the right time.
> We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways.
Bob's time isn't unlimited. There are surely instances where he was helping out Joe, Suzie, Darren, and James and had no time for Alice.
Based on your other comment, you seem to think someone being an unblocker/idea generator/dev lead is a "low performer" who weighs the team down. That's just fundamentally wrong.
It isn't wrong, it's right; because pontification of things (in a vacuum) yields no results. I cannot sell my customers Bob's ideas. All I can sell them is software that does something. The people that can do this without needing Bobs around are the people that will be rewarded.
The part that's often missed is the future outcome, when someone returns to this code to fix a bug or add a new feature. I believe it's incumbent upon those of us with some experience to ensure maintainability is part of the considerations.
Quickly shipping a thousand lines of buggy code that you then spend the next month fixing (by writing thousands more lines of code) is a good way to fool everyone into thinking you are productive.
why? most code is not some complex algorithm where 100 lines of code can take years of genius work to figure out. Unit tests, for example, have near linear proportionality between LOC and utility. Same for comments, same for standard business logic.
100 lines of integration tests are worth a lot more than 100 lines of unit tests, so it's not a simple matter of counting LoC.
Also, solving the same problem with less code is a lot more valuable than many think. Not only are there fewer code paths to test, the system probably has fewer unnecessary constraints and edge cases to consider. How do you account for negative LoC?
I can whip out 100 lines of bullshit in a few seconds. I can just paste in whatever Copilot gives me and as long as it builds call it a day.
It will take me far longer to come up with the correct 100 lines that is both maintainable and can be worked on by others down the line.
I can pad my lines of code in seconds if I wanted to before pushing the changes. That padding provides no business value and might even introduce bugs.
And how do you handle refactoring? If I come in and refactor everyone else's shitty padding by combining helpers and optimizing code, I'll have negative lines of code. Am I an unproductive worker?
Sure, most code is not some complex algorithm but lines of code is a stupid metric that is not representative of the work done and can be gamed by anyone knowing what they're doing.
Unit tests are useful if you write them alongside new code, but then become not useful since if you never change the code, they never break, and so are wasteful.
It's better to have tests more sensitive to failure, like integration or regression tests.
They’re still valid even if you aren’t changing code.
The key there is caching your results. Don’t run unit tests for code that hasn’t changed.
They still serve the important purpose of checking validity of the code under test though, so if they do get modified downstream at some point and they fail you then know the changes aren’t conforming to expectations of the system.
This of course assumes people aren’t writing highly coupled tests and that is more rare than I wish it to be
I am one of those people and work a fully remote job, but I had to earn that credibility with years of being a top contributor first. It would be difficult to just walk into the role.
I wrote a sibling comment alluding to the same, having been that person across a few different employers now. The struggles I had certainly, to a large degree, boiled down to a lack of trust (walking into a new team/department/company is hard on both sides!), but that wasn't the full story. IMO, management needs to have the right mindset to establish culture, too.
Yes and no, depends on the engineering culture and the management. I was successful in this sort of position as a full-time remote senior and then a team lead from 2016 til 2022. I changed employers and found myself in an environment that simply did not understand pairing, mentoring, etc. Management was oftentimes directly in the way, confused about loss of "velocity" and other trivial bullshit, despite the fact that the team was shipping in overdrive. I left at the start of this year and am now back in a position where these things are valued, encouraged, and happening remotely.
That would depend on the culture of your team and larger workplace. Healthy teams should be checking in frequently to talk about ideas, reviewing big things, scoping upcoming work, etc. If there's time reserved for deeply technical but loosely structured discussion like that, then everybody takes turns being that person. In that env someone could "specialize" in it and help inspire others to do great work.
It's the team that creates that kind of opportunity for feedback though. If the team has dysfunctions like rejecting deeper discussion or not working beyond jira tickets or checking out at meetings, etc. then it's not going to work. Someone that's good at that kind of supporting discussion will feel push back when fostering those discussions so it will fall off over time.
The teams that do the best work and are the most fun to be on can host those types of discussions though, even remotely. It's worth experiencing if you haven't!
I assume you mean the thoughtful person whose probing questions unlock and unblock everyone else.
Lunchtime conversation is only one enabler of this.
I suspect the person is Hamming, as he makes reference to this in his book The Art of Doing Science and Engineering.
This aspect of what it takes to be a Hamming is curiosity about what other people are doing; you can track this by reading shipped emails or lurking in slack channels, then reaching out individually to the people/teams involved when you wonder about something.
Hamming was intentional about doing this at lunch. The magic isn't lunch, it is in intentionally seeking the information and then acting on it.
Yeah the main thing I've found helps is if there's a regular Teams/Zoom meeting where everyone just pops in for like 30 min to ask questions. Then you can use that as the springpad to launch into one-on-one sessions.
You do need to cultivate a culture in the team of people being willing to lower their guard and ask questions though. And I think the key to this is just staying humble so people feel comfortable approaching you.
I've written several 100ks LOC/year at points in my career- but exclusively when working on new projects. When maintaining projects I might go a week at a time without writing any code solo, or I might spend a week trying to _reduce_ LOC.
I think my net contribution of lines of code at my current company is still negative. It was for a long time, but I haven't checked in awhile so I'm not sure if it still is.
Usually I end up adding more lines of documentation and tests and removing lines of application code so it's not easily measurable- on theme for this thread, heh
My problem in my last role when I read large Pull Requests is that they tended to be way more complicated than they should have been but because they worked and I couldn't single out a small number of specific problems, I had no choice but to approve. Still, I knew it would slow us down in the medium and long term but this bloat is completely invisible to management.
It has become taboo to say things like "This code is too tightly coupled", "You don't need to add an external dependency for that", "The inputs to those methods are too complicated; your components are micromanaging each others' state", "You're violating separation of concerns", "The cyclomatic complexity of this code is too high; you could simplify all your if-else statements"... When it's not my company, it's impossible to dismiss code when it works right now, even though it is likely to break later.
I can relate though I wish I could get into a position that I could say such things and not get fired. In some circles "This change is hard to me to read and understand" would be interpreted as "I'm an aging dinosaur who doesn't understand this new tech; you youngsters are too clever for me." (though I realize how completely wrong it is).
I'm 33 but I feel like I already have to make an effort to avoid the dinosaur label. I disagree with a lot of modern tech trends but I simply cannot express my view about them even though I could explain the problems very clearly and logically and can provide far better and simpler alternatives. Unfortunately, hype does not yield to reasoning... And sometimes, you're too far into the tech debt and it doesn't make financial sense to rewrite.
I’m 10 years older, my experience has been that getting to ask stupid questions is one of the joys of age/seniority/security. Very often everyone else in the room has the same stupid question but you get to look like a stone cold genius because you were willing to risk looking silly.
I guess maybe in 10 years I'll be working with 30 year olds who understand and value of that approach as I do today.
My current reality is that I'm a 33 year old working with 20 year olds who think they're geniuses who are going to take over the world in 5 years; from that viewpoint, I'm essentially a failed engineer because I didn't build a Facebook, Uber or AirBnB even though I had 10 years to do it.
Usually this kind of thing comes from “trying to keep costs down” at a poorly funded firm, usually startup-ish. I’ve worked places where the oldest engineer was 30 and it’s rough, quality and stability just aren’t in the average 25 year old’s toolkit.
> "This change is hard for me to read and understand"
Believe it or not, I consulted at one place where the manager decided I was the problem because I was consistently assessing problem code and team processes in similar ways. She asserted that "everyone else understood", even when they plainly didn't understand but where just going through the motions.
Said manager had a number of other issues as well. Worst gig I can recall having in the last couple of decades.
I would start being less diplomatic once I get the hunch polite phrasing isn’t getting through - “this code is badly structured, brittle and will make debugging harder”. As programmers being tactless is expected so might as well use it to your benefit.
In this case, I could have, but I felt my time was better spent thinking about why things were complex and hard to understand and made notes on that, mostly for my future self. Whenever I found the opportunity, I would include some of the reasoning and explanation, in written form, in my feedback. I didn't get much out of that gig, but I did end up with several thousand words of ideas and observations. I wouldn't be surprised if some future programmer on that project ran across something I left behind and found it useful, or at least comforting.
Edit to add: in 1:1s with the manager I was more direct. About the best I can say about that is "at least I tried".
I'm honestly not familiar with this "I had no choice but to approve" mindset. In the greenfield projects I've worked on there was always at least one person, sometimes several, who had the authority to just say "no, this is far too complex, scratch it all and we'll meet tomorrow to discuss next steps." Sometimes it ended up with breaking the PR into several more manageable pieces, sometimes it ended up with a wholesale rewrite / refactor of that component.
I didn't have enough leverage in that company to say such things and the project had already been running for a couple of years when I joined (not greenfield).
The last greenfield project which I managed from scratch, we didn't have this problem because all developers shared the same mental model of what we were building before we wrote any code. We had a lot of discussions beforehand to get to this shared understanding. There was literally not a single PR which surprised me throughout the entire project and I'm sure none of my PRs were a surprise to any of my team mates either. There was plenty of disagreement throughout but it was always fully resolved through discussion before we started coding each major feature.
In my experience it pops up when company politics get involved, or somebody gets attached to their idea about how certain things should or shouldn't be done. In that case often the safest thing you can do for your own reputation and appearance is to leave some very gentle notes that a certain thing maybe could have been done differently, but approve it anyway on the grounds that it works for now. That way you're not seen as an obstructionist, but if things do go wrong you at least have a written record so you can say "I told you so".
"You don't need to add an external dependency for that"
"You're violating separation of concerns"
I've found that kind of feedback to be useful actually. And when giving similar feedback it is received better with a small change in wording to make it more about the code and not the person. Even if that is the intention the wording does matter. For example:
"An external dependency isn't needed here, try implementing with XYZ instead."
"Split this function into x and y for better separation of concerns"
Removing the "you" removes some resistance to receiving the message .
Somewhat unrelated, but it's true that it's sometimes hard to give a reason to reject code that has a "funny smell".
Without going into specifics, there was a case where I reviewed a PR, asking "this isn't usually how people do file operations, are you sure this is really fine?" To address my concerns, they even wrote a specific test program to "prove" that there weren't any problems with the code. I reluctantly approved the PR since I couldn't just ask them to rewrite the whole patch due to just a hunch.
Lo and behold, after a kernel upgrade and file system change, that weird piece of code caused a multi-week panic for the whole team. The extra funny thing is that the test program above made it trivial to confirm and reproduce the issue once we identified this was the cause.
The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.
Being superficial wasn't invented in the 19th century. People are very oriented to things they can see, measure and touch, when the most impactful and insightful people are often the silent care takers, the teachers, those keeping things running smoothly.
When you do things right, people won't be sure you've done anything at all.
A lot of that is from Frederick Taylor, who invented “scientific management”.
He did experiments where he would have workers shovel piles of ash from one side of a line to the next, giving them a new shovel size each day. Found that the ideal shovel size holds 21 pounds [1].
The ideological assumption of his work is that management exclusively does the thinking and the workers exclusively do the doing. This falls apart when the workers have unique knowledge and insight that management does not have.
> when the workers have unique knowledge and insight that management does not have.
AKA every time.
AFAIK, Taylor himself wasn't nearly as radical about doing measurements and only acting on them nor about managers deciding everything and not listening to the workers as Taylorism preaches. His work was one of the many, many management theories that was completely modified to appeal to incompetent power-hungry wannabe dictators (and yet blamed on the person proposing the original theory).
Acting on the numbers you get is not intrinsically a problem: it's what the action is. Looking at how fast stories, function points or whatever get closed is important for planning what you can get done in a given time, and that can be crucial for project management and managing customer expectations. It's not acquiring the information which is a problem; it's not using the metrics which is the problem. The problem is not understanding what the metric can be used to represent (project velocity), and what it cannot (individual productivity);
Those are not important at all, or the top software projects would be using them. Linux kernel is doing fine without the velocity point story tickets. Agile "planning" which is used in worse software projects is snake oil.
It may be useful to collect metrics to get insights, but if they are publicized as a measure of performance, it's likely they'll be gamed, making them less useful.
Yeah, you have to do it all. Churn out stories AND mentor AND knock down "desk-side" work (random infra bullshit). I have been at big companies where no one lasts very long. Thier mental health suffers to a point where they have to leave so that they can go work at some other sweatshop for a while. The lull between giving their notice and the honeymoon at the new company is their only break.
The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.
Tangential but I was doing a web app for a client and gave a time estimate, which accounted for doing things properly (i.e. learning a frontend framework first).
He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable.
That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.
> That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.
And I learned that doing it my way will get me fired because the manager has asked to do faster.
The way I have learned to get around this is by making the manager publicly document the request to go faster. If they don't document, I don't see or act on it. Once they document it, I happily go faster and let it all crash and burn. Then when they inevitably try to blame me, I point at the public documentation of the request to go faster and let the blame fall on the person responsible.
that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent
if time is the only actual concern for the project's success, a good approach is to explicitly re-scope the feature list and start asking managers things like:
"do we really need feature X to release? can feature Y wait until after beta? did the request for feature Z come from a user or a stakeholder?"
document all that too of course ;) but then at least there is a chance for safety _and_ success
> that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent
Yes the project will fail. But if my manager only cares about speed, why should I care about anything more? Why should an engineer be responsible for a manager's poor decisions?
>Why should an engineer be responsible for a manager's poor decisions?
Because the corporate hierarchy demands it. Front-line workers are expendable, much like front-line soldiers. Corporations are not democracies, and neither are militaries.
If your job is to write and commit code, you are the corporate equivalent of infantry. In short: a grunt.
> your job is to write and commit code, you are the corporate equivalent of infantry. In short: a grunt.
And if I am being treated as a grunt, I will act like a grunt aka I don't care more than my bosses. I will even abandon ship at the sign of incompetence and point out the incompetence to others.
Regardless, it’s an important life skill to learn that it’s generally not enough to ask people to do what you want, you need them to actually “buy in” to what you want, and then they’ll actually care enough to at least try make it happen.
This applies to managers and their employees, or also when trying to get on the ground employees to adopt a product initially sold to their manager/execs.
"Buy in" is what you use for people acting in good faith. But managers aren't acting in good faith. They just want it done so that they look good to their own bosses. They don't actually care about the product/service. Their ask to "go faster" is a bad faith argument where there is no real need to go faster except for the manager to look good.
I don't feel the need to get "buy in" for bad faith managers.
Why is asking for requests to be in writing an "act of bad faith"? Literally cna't see a single outcome that would be an act of bad faith here.
If the project fails, and the manager tries to blame it on you, they are de facto acting out of bad faith given the request. Documenting it just identifies this. If the project succeeds or fails, but no one blames you, then the documented request is just there for the record.
Sure you can - you just have to be willing to throw what you have away. If the outcome of that is having to rewrite one of five experiments because it is a hit, that is a _great success_, not a failure.
But only in theory. In practice you would never get the time to rewrite what “already works”. And objectively, even with the best intentions, every rewrite comes with its own kinds of risks.
> where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion
This sounds like an improvement over the opposite, a code base that is rarely touched and uses eol frameworks. Software is a living thing and if you don’t act as a ruthless gardener you wind up a museum curator with 1990s DEC hardware running in the 2010’s.
The right balance of staying current and not reinventing the wheel is not trivial.
“If you choose the right frameworks” is a big if. Even within a framework, there is versioning and dependency management to account for. Consider the log4j vulnerability. The cost and risk of patching something untouched for 10 years is higher than something touched more recently.
In part, this is due to the risks inherent to change have been spread out over 10 years instead of backloaded to the end.
Practicing mitigating risks by proactively taking them has value of its own. The parable of ergodic cakes shows this.[0] What % of cakes will fail if 10 people each bake one, versus one person baking 10 over time?
That is a great example. By not taking account of risk on the front end by embracing change, the system gets progressively more expensive to maintain (extended support contracts) and the risk of eventual inevitable change grows higher. Further, the system becomes progressively less valuable compared with newer systems.
> becomes progressively less valuable compared with newer systems.
Indeed, business people do not typically model depreciation curves for software as they should. That doesn't mean that the plant control system becomes less valuable (the value is tied to the operation of the plant, probably for the lifetime of the plant), but in many other situations it does mean that.
On an individual level: So what? I stopped giving a f. I'd rather do what I believe is right than earn another $100k a year at a certain point. If it gets to the point of being laid off, hey, maybe it's the nudge you needed to find a better place anyway. Meanwhile, you could play the game all you want and still have your entire business unit shuffled away next year.
I'm not going to drive off a cliff just because the OKR tells me there's actually a road there but I wonder about some people...
> It sucks being that person today because everything is about optics and that person will get purged. I know from experience.
This is my company. Engineer skills, tech-debt, teamwork, camaraderie don't matter. Do as the management says, in the time they've promised to others or else....
Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor.
It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role is sound.
My experience at Google has been that TLs were generally strong engineers who were doing that kind of mentorship and product leadership, so to the degree that it's a "promotion" (same money, more responsibility isn't a promo in my book) it does seem to go to those who are doing it.
Now TLM (Tech Lead + Manager), however......there's a role that's set up for failure. Be a manager but be judged entirely on your technical contributions.
Is that a higher level position ("promoted" suggests that)? In my FMCG IT department I am the TL & "technical architect", but I am on the same level as a senior developer, just having in the top 3 priorities the coaching and mentorship of all technical people in the department and no code expected (I do write some as examples or templates). What is the TL level in Google vs developers and architects?
I'm the frontend lead in a company of about 200 people (mostly devs) these days, and the idea of being a force multiplier is spot on. I'm not there to be the best dev or the most knowledgable; I'm there to lead the conversation and amplify people who are saying good things. Having a pretty deep understanding of the tech is useful so I can tell what those good things are. I am absolutely not in the company to show off or take credit for what my teams do.
Where I disagree is with the idea of fighting with product owners. If there's a disagreement around approach or tech choices that's a sign we don't have enough information. Fighting or refining won't solve that. It's a signal that we need to do more discovery work and understand the problem better.
I never said one should be fighting. My point is that POs/PMs should know the domain at least as much about the domain as TLs do.
The problem is not needing discovery work or understanding the problem. The problem is when the Tech Lead is the one who's providing all the data for that discovery, or helping them understand the problem better, because of lack of expertise of PO/PM. Or having to push back because of incomplete knowledge.
If there is lack of information or incorrect information, POs should be able to get that information themselves. If a TL is the sole source of that info, then it becomes an issue.
IME this is very common. And it takes too much time of a Tech Lead's day.
The TL role is a little restrictive IMHO. I’ve worked with very junior people who have a very effective ability to pair and improve others’ effectiveness. Perhaps as they learn they also teach.
> I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code.
This is a strong statement. There are both people who are writing throwaway code and people who are writing essential code that match the description.
And one will never get to be the latter part without going through a phase where they are doing the first.
One sign I see if a healthy workplace is one that tracks bugs and QA issues downstream against the same unit of work.
You quickly get a sense for what teams and even individuals are introducing the most bugs and issues.
If you can close tickets fast and your bug rate is low: that’s key, but I have found often that the people introducing the most bugs and issues into the codebase that others have to spend time dealing with are those that seemingly close their tickets rapidly every sprint
If your leadership is tossing these incredibly valuable engineers aside, then it's time for you to toss that leadership out. You can do that by leaving, or talking to management about this, or unionizing. It's crazy to me tech workers aren't unionizing anyway.
(I am from Europe, so I have a fairly good idea of what Unions can do, also thanks to having lived and worked in two different countries).
I am not against Unionizing "per se" but the role of Unions has never been "tell the management how to run their business". There has been some cases of (smallish) company being "acquired" by their own workforce, and the Unions might have helped with formalizing the deal, but this is rare, and anyway happens only when the company goes bankrupt or decides to shut down.
So I do not understand exactly what you mean here.
I know how Unions work. The OP stated: ...it's time for you to toss that leadership out. You can do that by leaving, or talking to management about this, or unionizing.
A Union can organize and sustain a strike. But they cannot "toss leadership out". Not the CEO, the Board or any manager at any level.
They could theorethically "blackmail" a company saying "strike will not end until X is fired" where X is a PM or manager or whatever but I never really heard of anyone trying this tactic, not to say actually succeed...
Unfortunately union / labor movements in the US suffer from a big problem: due to historical circumstances they’re very combative. The labor movement here never grafted the idea of being business oriented on behalf of workers into the movement (like in Germany) rather, they treat the business as the enemy pretty much from the outset.
Some of that is indeed earned by the businesses reputation, but ultimately this is what I think spurred the decline of union membership in the US because businesses don’t get a lot if any value out of having a union around and the organized workers often find the benefits stagnant after some time
That is because of historical circumstances, but it continues to this day because it's encoded in the law; we don't have codetermination or sectoral bargaining.
I have seen first-hand the negatives of unions in Italy: there are downsides of powerful union control. But in the US, a strong argument can be made that unions played a very major part (along with the GI Bill of course) in the growth of the the middle class from 1950 to 1980, and their busting, starting with Reagan, likewise was instrumental in the dwindling of the middle class and the dramatic rise in wealth inequality.
Unions may be different in your part of the world. In America, it's one of the only ways for blue collar or other production-oriented workers to have any degree of leverage at the negotiation table. We are treated like cattle in the workplace, and though unions come with their fair share of problems (due to it being yet another leadership structure to work within), the idea of workers holding power as a group is essential, because it reflects reality. None of that VC money is getting a return without workers to do the work. Most places in America are not unionized, but the ones that do pay better than other work in the area, even after union dues.
I see it as very much a union-by-union thing, much like you would an employer.
Now, some programmers may be able to negotiate good terms for themselves, but the vast majority of that stage is simply how silver your tongue is. Why should you be paid better because you got a better charisma roll with the interviewer? I would want my coworkers to be paid the same as me for the same experience. A senior with 10 years in the field, naturally, would be paid much more.
It's strange you say developers can negotiate, when there've been quite a few layoffs as of late and we see plenty of stories of people having trouble staying in tech. Which is it? The only thing that can give you credible sway is learning rarer or more in-demand skills, and putting together projects that show you understand how to use them. And for how long will that last? A union is a lot harder to fight than an individual.
But yes, there are bad unions. If they're as bad as your alleged blue collar friends say, let's name them! Sometimes their politics or dues or seniority system sucks. Those systems deserve to be put on blast.
But strangely, no unions listed in your comment as bad.
It’s funny you mention it as a charisma roll, because it’s not really a roll, is it? High charisma is high when it’s with your interviewer, when it’s with your peers, when it’s with your business stakeholders. High charisma is useful in getting a job, in arguing for addressing tech debt, in pushing back on unreasonable timelines. Why would you not consider charisma in a job interview?
Charisma isn't something that's there or not there for everyone, like green paint. How you come across to others will differ based on their biases.
I don't consider charisma very much because I connect it to dishonesty. If someone's put a lot of effort into coming across as charismatic, it means they have considerable skill in psychological and social manipulation. I would value that in a salesman, where it makes sense. Otherwise it's just masking 2.0.
The primary concerns in an interview should be "can you do the job" and "can we bear to work with you". The rest can be worked with.
I don’t know. I’ve met several people who see themselves like this and who are seen by senior leadership as being like this, but nothing they say tracks, even a little bit, with what I know about the system and problem space from my time actually immersed in working on it.
I love writing code. I usually "score" on the higher end for LoC which managers like to praise me for while simultaneously saying LoC isn't everything but there aren't many good measures. Lol.
But! In my defense, I delete as much code as possible. Love deleting code. Not sure if that counts in the LoC. I see lots of others copy and pasting and leaving little bombs everywhere. I refactor, clean, delete. So.. hopefully my LoC is mostly that and not adding fluff.
> There is a very good chance that the same feature set could have been implemented with just 10K lines of code, less buggy and in half the time
A significant part of my personal code review process, is going back through my code, and factoring out complexity. It takes time and humility, but is very much, in my opinion, worth it.
Documenting my code is a trick that helps. When I am writing why I did something, I sometimes reflect, and say to myself "Didn't I just do this a few lines back?"
My code tends to be complex, by necessity, but it should be no more complex than absolutely needed.
A big, big tool for that, is OOP inheritance, which is considered "bad coder" smell, these days.
A big, big tool for that, is OOP inheritance, which is considered "bad coder" signal, these days.
Is it? I’d agree that there’s increasing awareness of the limitations of OOP, and I’d agree that using inheritance excessively can be one of the limiting factors, but I don’t think I’ve ever personally seen anyone criticised or penalised for using inheritance appropriately.
I've done a lot of OoP and my opinion these days is that if the reader needs to understand polymorphism properly to understand your inheritance, it's too complex.
(Exceptions exist, of course, like libraries inherently dealing with reflection)
Well, to each their own. I like to understand everything I do, at a very deep level, and I really enjoy learning that kind of stuff. I started as an EE, so my understanding sinks down into the FET junction. My first software was machine code, so it’s been a long, strange trip.
One thing that geeks love doing, is telling other geeks they are bad at what they do. It gets a bit grating, but I’ve come to the realization that I need be true to myself, because it’s a losing proposition, hanging my self-respect on the opinions of others.
I do what I do, and get the results I get. I don’t spend much time, worrying about how I compare to others.
One of the benefits of working at the direction of my own muse.
It's good that you know and understand things at a deeper level.
That should make you even better equipped to design simple interfaces that require as little depth of understanding as possible from the next person.
Similarly I've happily spent my couple of years with functional purity and higher-level types in academic languages - function signatures sometimes orders of magnitude longer than the implementation itself - yet I dip into those depths only as necessary and try to keep my TypeScript interfaces as "stupid" as I can get away with without compromising on semantics. Enums are too fancy for me. I try to keep state at minimum but there's a 'let' every few thousand lines or so.
And all that venturing into lower-level concurrent C++, agent systems, parallel programming, erlang? You ain't gonna know about any of that looking at my concurrent Rust.
> One of the benefits of working at the direction of my own muse.
Oh, well, what I'm writing above is from the point of code meant for collaboration - either open source or professionally. If you're coding for yourself only, or in academia, by all means stop trying to please the crowd and start cranking out some poetry!
Some of that is the fact industry never really evolved OOP approaches and they tended to trend to toward heavy and complex. Peers aren’t great with the power OOP can have.
I’ve also seen composition go sideways too.
Sometimes it feels like nobody takes software engineering seriously anymore, if I’m being honest
This is why software craftsmanship is rarely recognized. When you build with craftsmanship so features are easy and fast to add on top of what you built because you thoughtfully the most likely ramifications of the current requirements within reason, operational excellence is easy to accomplish because you sat down with front line operators and took the time to understand their incentives and daily operations pain points from a first-person perspective, and so on, you aren’t the one who is recognized with the commensurate credit, those who benefit from your work in the future are the ones who grab the limelight as if they did your work, unless the leadership are themselves highly technical (and many times, not even then). Incentives currently in most of my clients are mostly aligned to the fulfillment of keywords and not an outcome.
“Produce a procedure documentation” gets keyword fulfilled into “here is a document with some steps”, instead of “here is a procedure we wrote, used spelling and grammar checker upon [I’m still shocked so few take the few seconds to correct as they go], run through an automated editor, then iterated through random people from the user population until someone who never saw it before accomplishes the procedure without assistance”.
Some startups succeed because they’re forced into conscientiously thinking through these ramifications in just the right contexts because they’re so close to the coal face. It is also possible to overdo this in the wrong context and end up bikeshedding.
Friends of mine worked at a place were they got a rock star programmer that churned out thousands of lines of code a week. And they eventually found themselves relegated to the role of cleaning up the mess. So they all quit.
Edit: Take rock stars 3000 lines of code a week and divide by one rock star + six experienced developers now doing nothing but bug fixes and it doesn't seem so super.
> sucks being that person today because everything is about optics
Not everywhere. I’ve casually suggested five big changes to the startup I’m currently working for that others ran with. I’m proud that my ideas even make sense, and my reward is that others come to me for leadership. I would get more glory if I had also carried them out. But I’d rather do the things that others can’t, than what shines the most.
> 2000 lines of code per week terrifies me... That's over 100K lines of code a year
That would be incredible (and scary). But productive people I’ve seen the contributor metrics for who write vastly more than they read, still have a number of deleted lines growing with their added lines in some proportion.
There is a style of less re-use, more copy-pasting that just grows faster but also needs constant refactoring in trivial ways.
> That's over 100K lines of code a year. Think of the unnecessary complexity.
I've got a colleague like that. It's all good and management praises him, but this is a time ticking bomb. When he leaves, someone will have to maintain that code.
You’re largely correct but I think your comment might not nail the root cause (not saying you don’t know this, just that your comment doesn’t emphasize it).
When a market is competitive, the things that matter are roughly: hard work, candlepower, and optics/neurotypicality/maneuver in that order.
When a market is fairly sewn up that order becomes roughly: optics, candlepower, ethical flexibility, hard work in that order.
The hard-ass nerds who don’t give a shit about corporate culture du jour are treated like royalty when someone might fuck your business up.
While “purged” is a strong word, I take your meaning, and whatever we want to call it, it happens when competition is largely pro-forma.
Human beings will do anything to avoid selecting on merit except lose. That’s just human nature. Being mad about it is like yelling at the wind, but compared to even a decade ago, I’m not sure how high I’d be holding my head in today’s competitive landscape for high-prestige achievement.
I worked at companies where de facto lines of code were a metric of performance. Then when I moved to first company where "how" was more important I had a heavy anxiety where I didn't write a line of code for a couple of weeks. I was worried I'll get fired. We were just having meetings and just talking about problem at hand and throwing ideas, without actually trying to implement anything. Then when the ideas how to tackle the problem matured, we would try to turn it into code, like a proof of concept thing (tested with people looking for solution) which could be thrown away. Eventually we would get the solution to the problem and most of the time it was flawless. In the code heavy approach, company would have ton of bugs, support requests, fixes on top of fixes, sometimes it turned out the feature was misunderstood, but it was already so embedded in the system, it was difficult to remove. So things were piling on.
The other approach? Boring. We had some bugs here and there, usually when something was not covered by the tests or some edge case we didn't think of. But I never forget the anxiety...
We detached this subthread from https://news.ycombinator.com/item?id=37362066. (There's nothing wrong with it but it's a bit generic and I'm trying to make the thread less top-heavy.)
Having been in the industry since the around 1990, I can tell you that in the first half of my career we had no code reviews, no scrum, no story points, no unit tests.
How on earth, you might wonder, did we ship software that worked?
I then saw all these things come down the pike one after another during the last half of my career.
Clearly to me every one of these benefit management who found themselves apparently unable to function without numbers, graphs, data of some sort. It has been a very obvious (to me) power struggle: management trying to get the upper hand and wrest any and all power (and autonomy, and decision making) from engineering.
It has been sad to me to have heard some new engineers come on board who like these things. It's just as well I retired when I did: it's probably me that is the odd man out now.
I'm pretty sure there were companies doing stupid things in the old days but in my experience, back then managers were supposed to know what developers were doing, and if they were delivering value or not.
They did all that by walking around, chatting with everyone, helping devs, assigning tasks depending on the expertise level, sometimes doing boring work (like manual testing) to help devs, etc.
Of course, if a manager that has to handle Jira and Scrum meetings all day, then it gets difficult to do that.
Definitely cultural. I have been watching engine teardown videos. The difference between the Japanese motors and American motors is stark if you know what to look for. Engineers were clearly in charge of designing every aspect of the Japanese motors. American engines have so many compromises and they flip-flop on internal parts and designs, that look whilly-nilly in comparison.
It's obviously cost cutting niggling and get-it-out-the-door histrionics causing this chaos. There is significant impact to longevity and durability, and required maintenance. Very wasteful from a global warming perspective.
Watch out for these late model ICE engines...do your research. If it's "newly redesigned!" step back and dig in.
That's fine. Myself I have little use for them, I prefer functional testing. (Also, before unit tests we leaned on parameter checking in the live code — a kind of always-on unit test I guess).
Management though use the "percent coverage by unit tests" as some sort of safe/buggy software metric.
Management at one team I worked on was pushing for minimal 95% coverage with unit tests. I thought it was odd that they were so singularly focused on this issue. The impression I had was a that they felt that if you have full code coverage with unit tests, and the test pass — you can lay off the QA team because you are assured that you are shipping perfect software.
The thing is: Different levels of experience need different measures of success, up to the point of leeway from the normal measurements of success.
Like, for someone in tier 1 / tier 2 helpdesk, or the regular developer pushing relatively normal tickets through, simple ticket or story throughput is one indicator of productivity. As long as you pair it with some success measurement, like re-reports from people within a short time, or work caused by the implementation. Or just feedback from the rest. Someone has to put down code to make the feature work in the end.
But this changes when you get more specialized and overall more experienced. If we bring a new technology into the team, my productivity based on the first metric will drop to zero. I'll be busy supporting other people. Or, the incidents on my desk will be far more weird ones. Other people get clear click paths and an exception. I had to debug JVM crashes due to faulty hardware. That took a bit longer than an afternoon in a debugger and adding an if-statement, if I may embellish a bit.
But that's why soft skills become important. It's concerning how little that manager knows about his team. But it's also concerning how Tim didn't make sure his manager knows what's going on. For example if we're bringing in new tech, I'm informing superiors first that I'll prioritize support of team-members with the new tech just below business critical incidents and I most likely won't do any regular work for some time.
I’ve met a lot of project managers who are competent and see the bigger picture. They actually pay attention and understand why the numbers are what they are. They respect that the numbers are a very flawed tool and cannot be utilized without context or understanding.
I’ve also met a lot of project managers who are there because they’re incompetent. They lean heavily on “agile” and “best practices” and say moronic stuff like, “can you show me how many lines of code each developer has added this month?” (this happened to me. I fought it hard, explaining that it’s not a meaningful metric. I showed him a month that I wrote -1500 lines of code).
I feel like I could say the same about managers, coders, executives. The incompetent exist everywhere and they lean heavily on bureaucracy to protect their existence.
> He would not crowd them or railroad them, but let them take the time to learn whilst carefully crafting moments of insight and learning, often as Socratic questions, what ifs, how elses.
I do not like people who do this. just tell me the answer. this is such a gigantic waste of everyone's time. you figured something out months/years ago, great for you. give it to me NOW, so I can get on with my day. if we BOTH run into something unknown, we can tackle it together. but dont force me to go through the same painful learning process you went through. YOU suffered, because at the time no one knew how to do whatever it was. now that someone knows (you), your job should be to spread that knowledge across the business as quickly as possible, not hoard it to yourself until someone is deemed "worthy" of knowing it.
> You'll implement it, get on with your day, and not at all think about why the answer is what it is.
this is an incorrect assumption. some people (like me) have an analytical mind. if I am given an answer, I will usually reverse it back to the question, so that I understand how it came about. or I will ask follow up questions until I have that understanding.
all this method is doing is forcing multiple people to go through the discovery process, when all that should be needed is for one person to do so. its a waste of business resources. person A can share with person B, then person B can go on to make their own discoveries. we dont need to force every employee to discover EVERYTHING on their own. thats just a huge waste of time. it would be like forcing everyone to discover Pythagorean theorem on their own, instead of giving them that tool and letting them use it to create other stuff.
Just because you're a special snowflake (you aren't, but keep believing it if it works for you) doesn't mean that the discovery process isn't the best approach for teaching most people things. Hearing or reading something is the lowest form of learning and generally results in the lowest retention.
> thats just a huge waste of time.
Instilling knowledge and discovery rather than rote completion of work based on others' ideas is far from a "waste of time" for people who actually understand the learning process. Growth is generally desired in the business world, even if it results in a short term hit.
Please don't cross into personal attack or otherwise break the site guidelines. We had to ask you this once already recently (https://news.ycombinator.com/item?id=36274535) and you've been doing it elsewhere too, unfortunately. That's not cool.
I've worked with several types of people. For me, the best mentors were the ones who would answer questions I had with the full answer, often with details. Then they got on with what they were doing while I went back to my desk and tried to understand/retain some of what they told me.
I'd personally find someone shadowing me and asking questions super annoying.
I don't think this would work with all teams, the takeaway I got from the article is about artificial metrics.
Now when you Google “Tim Mackinnon programmer”, the 5th or 6th result for me is a link titled “The Worst Programmer” and the little descriptive blurb below that says “His name is Tim Mackinnon…”. I know the author was click baiting and flipping the story on its head, but I would be a bit annoyed if Googling my name + programmer surfaced something like that.
Yeah, this is a great opener to break the ice with during an interview.
You can even add some prestidigitation by having them take 30 seconds to Google it and your name comes up. Play it off as a joke and now everyone has a little smirk/chuckle over it.
Now they know you have a good personality and can tell a funny joke about yourself. Goes a long way to putting you in that “I can work with this person” category.
Also, if they can’t appreciate the joke, that’s an easy red flag for you that you probably don’t ever want to work for that team.
Can you reassure me then with the data that backs up your claim? Because in my very long career I've seen a lot of people use heuristics when deciding who to follow up with.
"According to a 2018 CareerBuilder survey, 70% of employers check out applicants’ profiles as part of their screening process, and 54% have rejected applicants because of what they found."
HR are not going to reject an incredibly experienced senior guy with a CV as long as your arm because of the title of a blog post. Your quote doesn't even suggest they would, and I'm not going to cite any evidence because it's honestly just a patently absurd proposition.
If you're letting HR who have no idea what they're doing, go from "a hundred CVs" to "two openings" you are bad at your job.
HR's job, like legal, or many other departments, is to facilitate what you actually do which in this case means work like chasing references and ensuring the candidates have somebody who can answer stupid logistics questions without bothering the interviewer, not figuring out who is the best fit for any particular job, that's the job of the people making the hiring decision.
Maybe if you're hiring fifty people to stand outside in the rain holding signs you can let HR pick who gets a job. Picking software engineers, especially if you actually care whether they're any good, is not the purpose of an HR department.
> If you're letting HR who have no idea what they're doing, go from "a hundred CVs" to "two openings" you are bad at your job.
What I said was different. How many CVs should we eliminate before calling people back for the two openings? What if the pile is 500 CVs? Call all of them? I guess you stop coding for the next two months and that's ok? Or maybe you let HR help you sort the CVs by priority.
> who have no idea what they're doing
I've worked with some very talented HR people. Maybe you haven't been so lucky.
> HR's job, like legal, or many other departments, is to facilitate what you actually do which in this case means work like chasing references and ensuring the candidates have somebody who can answer stupid logistics questions without bothering the interviewer.
HR does more than facilitate. They protect the company from legal threats, just as one example. In the case of needing to trim down a huge stack of applicants to an actually manageable stack, then HR will do things like search the internet for people's reputation. If you think that's not their job, that doesn't change the fact that they are going to do it anyway. HR very often has a say in candidate fit. Especially if HR is responsible for company culture, as is often the case these days.
> Picking software engineers, especially if you actually care whether they're any good, is not the purpose of an HR department.
At most companies the HR department is pretty involved in the hiring process no matter what the position is. At smaller companies maybe less so.
Or I just understand the realities of having to sort through large piles of CVs while having a time limit. And that in the real world HR will indeed use heuristics, even ones that don't appeal to our sense of fairness or effectiveness.
You've offered no alternatives other than your schoolboy insults.
Alternate lesson: If your manager is telling you to complete tickets, don’t go months and months not doing that thing until you’re on the verge of being fired because — despite being a valuable member of the team — your manager is all confused.
Communication skills. Week 1 Tim could’ve brought up the issue of overall developer productivity with his manager and his manager would’ve at least been aware that Tim wasn’t just playing Minecraft all day.
Yup. This idea that a developer can work his or her genius in a dark corner is flawed.
If you aren’t communicating what you’re working on, it’s hard to get credit or recognition. And it’s not an ego or bragging thing: It’s just fundamental team communication.
For example, there may have been constraints that the manager knew about that sheer velocity was key for some reason. Or maybe the manager disagreed that Tim was adding enough value floating around all day. Who knows. But if Tim and his manager were in open communication, at a minimum there wouldn’t be confusion so great that a good engineer almost got shit-canned.
> You see, the reason that Tim’s productivity score was zero, was that he never signed up for any stories. Instead he would spend his day pairing with different teammates.
Pretty clickbaity title. This isn't a story about a bad programmer, it's a story about a bad metric, and an even worse manager who followed it blindly
> Pretty clickbaity title. This isn't a story about a bad programmer, it's a story about a bad metric, and an even worse manager who followed it blindly
The clickbait is made so that this document can be shared with a future shitty manager. If you send them a link titled "The Worst Manager" - I assure you their first reaction will be to figure out how to get rid of you.
Managers are the bane of this industry and sadly, engineers have to spend an immense amount of time dancing around shit managers.
a manager that truly relies on story points as a direct metric of productivity wouldn't be reading blogs like this in the first place to make themselves better. the article is preaching to the choir of engineers and at a minimum half way decent managers nodding and upvoting. the ones that truly need to read this and embody it will never see it
Ignore the others. It's a quick read and a good story, and I think most engineers or engineering managers could take away something from it, even if just reinforcing that your already know.
The fact that the HN crowd, the "selective view" have downvoted my comment and not the one saying clickbait titles is good is enough for me to be reminded how braindead the community is.
It's entirely possible that the subject of the article is a terrible programmer, if he were to sit down and write or maintain something as an individual contributor.
I've worked with people like that, who were pretty bad individually, but brilliant when part of the right team.
Writing code and directly enabling the productivity of others who are writing code are different skillsets.
Obviously there's some overlap, but you're most productive in Tim's role in you're complimenting the skillset of the person writing the code.
It’s like Draymond Green. Individually his statistics suck. He’s jokingly called Mr Triple Single (a triple double is a major achievement, a triple single not so much). But he’s such a fantastic defensive coordinator and playmaker that his impact metrics on the team are massive. Like practically comparable to Steph, his more lauded teammate, in some stretches.
A common refrain in basketball is that people forget it’s a team sport. Doesn’t matter how good you are individually if your team sucks (see Michael Jordan in 1988 or Lebron most of his career). Similarly programming is a team sport. Individual stats are not the same as team success.
Yeah that's what I meant by impact metrics. In the 2015-2017 playoff runs Green's impact is almost on-par with Curry. But for most people who watch basketball, they just look at the box score and don't look at advanced stats.
Not even just playoffs either, I think his rank in that three year RAPM range was fourth or something staggering, after Curry, Lebron, and I think Kawhi? My go-to RAPM site that did all the calculations was taken down so can’t currently cite the numbers
Standard plus minus is pretty crude since it obviously doesn’t filter out any context, and the ones that do[0] tend to be a better reflection of a player’s impact in their given role, not their overall quality, which is something that drives me up a wall with the nba analytics crowd.
It’s easy to fall victim to the McNamara fallacy (I’ve certainly been guilty of it), before you start understanding the innumerable intricacies in the domain. And basketball is the only domain I probably know better than 99% of HNers lol.
That being said, GP’s general point about Draymond is very true. Yes he’s one of the best defensive players of all time and one of the smartest as well. I think the main point is his incredible self awareness (yes get the jokes off). On defense it’s more subtle, such as not over committing and leaving his man etc but on offense is where it’s obvious. As his own shooting has fallen off a cliff, more and more when he’s dribbling unguarded he frantically looks around for Steph or klay to flow into a dribble hand off to pry them free for a shot.
He’s talked extensively about the criticism he’s faced for lack of shot attempts, with his rational being why would he ever shoot if he can instead try to get Steph a shot. He’s also mentioned if Klay hasn’t touched the ball in a few possessions, he makes sure to get Klay the ball with at least a decent look; otherwise the next time Klay gets the ball he’s shooting it regardless of how bad the shot is. He also frequently pushes the break[1] to catch the defense off guard and before they can set up.
He is still a negative offensively, but why I appreciate draymond so much is for the above reasons and the myriad other subtleties he does to maximize his benefit to the team and diminish the detrimental elements of his.
And lastly, standard plus minus is still a hell of a lot better than box score garbage, I don’t mean to crap on it.
(Steph actually ranked higher than Dray last year in pace (seconds per possession) on/off which is why separating Draymond himself is so difficult. Their relationship is certainly symbiotic, but Draymond is the one that optimizes for best interplay of their skills)
And similarly to sports, there are devs who understand this, and devs who actively refuse to do things like pair, mob, or collaborate and just want to be handed work pellets so they can pick up their headphones and go to la-la land.
I don’t expect predigested tasks, and I’m fine with participating in broad strokes planning. But I need peace and quiet when I’m trying to concentrate on writing the code.
In this case, Tim from the blog post is a football defender or a linebacker if you're an American. Measuring them based on the amount of goals they scored or a touchdowns they caught is stupid. Instead they're stopping costly errors and providing the foundation that allows others to go on and score. You're probably not going to win very much if you field 11 strikers or 11 wide receivers.
It is also possible if they fired this guy, and replaced him with another developer that only did points that the organization would be more productive.
Without quantifying it or comparing to an alternative, this is just feel good commentary. If you deliver any value, that does not consequently make you a good business decision. You have to pit your value against your cost and the companies best alternative option.
Also, if a company measures my value in widgets, I have found my career does quite well assuming widgets is the right way to measure my value. Assuming you know better than everyone in management is prideful and not good teamwork.
Your last paragraph just said that if you hire people and tell them their earnings depend on $METRIC they will optimize said metric.
The argument here is which metric, or are metrics good for anything? [1]
[1] Except ditch digging and children. It is well known that 9 people will dig a ditch in 1/9 the time one person will, and 9 women will make a baby in 1 month instead of 9.
The answer to your scenario is `yes` with a high probability (taken from my magician's hat), but only in the short term.
People like the one described in the article prepare a pipeline of good engineers, who also have experience in the domain and in the organization.
So if one cares about fast delivery, get a good number of sr engineers who work on their own thing, share little and are not encumbered by each other. If a company needs to deliver urgently this works, but is an (expensive, short term) option.
One really good developer I worked with wrote excellent code and also terrible code that had to be replaced immediately — and both made him great to work with.
The value of writing good code is self explanatory. You probably use some of his code today.
But he was also great in a firefight: customer is dead in the water and it might be our fault. He’d show up cold and “jam his fingers in the holes in the dam”: quickly figure out what was wrong and then rapidly write and install the most hideous spaghetti code that cot the customer up and running. Code that could not be checked in, or be refactored. Eye-bleeding stuff. Someone would have to take the time to engineer a proper fix, but the immediate crisis was averted.
I was actually much more impressed by the latter skill — among other reasons it’s simply rare. Also he was just a nice guy and everybody loved him.
(Won’t name him since I described some of his code as hideous)
>I was actually much more impressed by the latter skill — among other reasons it’s simply rare
Not exactly something to encourage, but it sounds like he has experience in competitive competitions, where generating code to a problem on the fly is necessary. It's not something you can't learn yourself, but rote memorization of common problems and solutions (to the point where you can mechanically type down some algorithm from memory) is the bane of my existence
Don't competitions usually have completely different kinds of problems than what you typically run into in production fires? When I think of competitive programming I think of algorithms and puzzles, not network errors and data corruption.
In my experience production fires are rarely put out by rote algorithmic knowledge, the skill is more having a detailed knowledge of the inner workings of every layer of the system so that you can come to the right conclusion based on the very limited information available in the average production monitoring system.
This is my understanding as well. Rare is the day I’ve solved a production firefight by editing some algorithm - it’s almost always arcane configuration, restarting services in the right order, some network thing flapping/dos-ing the rest of the system, some service aggressively restarting and dos-ing others, actual malevolent dos, noisy neighbors, resource starvation, etc.
Yes, it's not the full equation. But that type of environment gives you a mindset that isn't present in most other types of coding. The ability to think under pressire, identity the fastest solution, and store a number of approaches in your head should you encounter dire edge cases.
.
>the skill is more having a detailed knowledge of the inner workings of every layer of the system so that you can come to the right conclusion
Yup, and that's transferable skills from competition coding. You're not juggling algorithms in your head per se, but you juggle whatever tribal knowledge needed as options to cycle through. That combined with the above mindset can lead to such skills.
It still seems a bit of a stretch to jump to the conclusion that someone who's good at fighting production fires probably has experience with competitive coding. You could maybe conclude that they would be good at competitive coding were they to try it, but competitive coding is way less popular than just... having a career in software.
Yes it is. Putting out fires, quickly, is very important.
The problem comes later when the breathing sapce arrives to regularise the fix and replace the band-aid with good quality code.
At this point no fire is burning, the problems are not immediately visible, and it takes very good management, right up the stack, to fix that sort of problrm.
> Not exactly something to encourage
Yes. Exactly right. Because the band-aid with all its ugliness becomes the permanent fix because there is no revenue box to place the work in takes to fix it into
>Because the band-aid with all its ugliness becomes the permanent fix because there is no revenue box to place the work in takes to fix it into
Yeah, that's what I was getting at. Especially in my industry, we don't get too many chances to convince the product managers to "go back and actually fit the code". From a business sense, it's a great skill, but business realities equate it to the ability to plug up a dam with a cork.
I'm one of these firefighter type, and it's causing some frictions with others developpers, because my code is not great and not future proof.
But I get the job done quickly, and lots of my quirky code have saved the day, either by solving an emergency or winning a tender.
It's difficult to communicate with "perfect minded" developpers, because for them if code is not thought-out, then it's not worth anything, even if they understand the need for speed. Of course they think the reverse about me^^
We're set up a weekly meeting to alleviate the issue and it's working OK. The hardest is finding out which "type" is the right one, when it's not an emergency but there's a tight schedule/unclear specifications... At least we make a common decision
So basically he just had the wrong title? Sounds like a great engineering manager or lead (in a company where that involves less code writing) or something. But his title is an IC role. But if he's spending all day pairing and not writing code then yeah - that manager seems to be correct, that's not his job? Why isn't he taking on any stories?
I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few teams there and you could immediately tell how the teams measured points by the stress level of the developers.
Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week.
Teams that gamed the system and understood the impossible task they were assigned always gave the highest points total to a ticket they could or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers.
In an environment like that playing by the rules is a suckers game.
When I eventually quit, every sr engineer at the company; 7 total, followed me within 4 months.
> Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week.
So in the short term, the company benefited, yeah? They got more work out of the same people than they would have if they didn't apply the pressure.
Reminds me of an old boss I had who would flat-out say that to get a project done we would "hire someone and burn them out" - he planned to only get six months of useful work out of someone, and if they were stupid enough to stick around for high stress and low pay, that's just a benefit to the company.
The question is whether you get more volume but lower quality: a team doing 60 hour weeks on a regular basis tends to be a team baking in lots of technical debt and skipping “slow” things like “do we really understand what our users really need?” or “did we correctly architect this?” Everywhere I’ve seen this there’s been a lot more rework and things like high infrastructure bills because people have [correctly] learned that the business doesn’t care about quality.
Sure, if they were going to do layoffs in 6 months anyway, I guess this anti-pattern was coporate's wet dream. them quitting means they don't even have to bother with severance packages.
But it sure is a shame we're past the days where you actually want to retain and nurture tribal knowledge. imagine if other engineering disciplines simply hopped companies every 2 years, or if they cut half their civil engineers for a better earnings call (thankfully, he government doesn't have "shareholders". just taxpayers to disappoint).
"So in the short term, the company benefited, yeah"
In hind sight, they did not. The company is publicly traded and recently sold itself for parts to avoid bankruptcy. They are in a very niche industry and are notorious for their production environment going down, and massive data corruption in their clients data set. There are worse things as well but I am trying to be at least a little anonymous here.
We called that Scrumflation at a past company. Didn't finish everything for the week? Claim the ticket was done and open a bug for the uncompleted work.
My anecdote about this is a case where I was an external consultant in a company.
The management decided to base bonuses on "number of open tickets assigned to a person measured on day X". Smaller being better.
(Un)surprisingly I got a bunch of tickets assigned to me on day X-1 and they were reassigned on day X+1. I didn't mind, since my bonuses were determined by customer satisfaction =)
> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers.
But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns.
I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds like the devs who you think gamed the system, were mostly behaving the way scrum is meant to incentivize. Happy, stress-free development that delivers consistently improving software.
(Minimum point totals per week leading to inflated point values is terrible management, though.)
I think what the GP means by “gaming” the system is that the teams did all the technical activities of scrum without providing much or any business value.
The issue with scrum or any process that involves estimating is that every software project will inevitably have some risky element or difficult to estimate task that is essential to the execution of the project. Scrum will incentivize teams to avoid the essential work and guide them towards work that is easier to estimate.
Certainly having a good product owner can mitigate this because she can do the work of identifying and breaking down the intractable to something more actionable.
But in that case you’re depending on the people on the team to make good choices. Smart people can do that regardless of the development process they’re using. It’s unclear what value scrum brings to teams at all. It doesn’t make bad teams work any better and it restricts how smart teams can operate.
One thing that scrum does give is it provides management metrics they can use to measure performance.
"every software project will inevitably have some risky element or difficult to estimate task"
You are exactly right here. At this company though, that risk on a personal level could mean a pip. So the happy teams inflated the story points massively to ensure that any or no risk was accounted for and they survived to code another day.
“Story points” help you predict your work in the future. Knowing what and when you deliver can be valuable!
Say you’re developing software for the next Super Bowl broadcast - it’s useful to know whether you’ll deliver what you said you would. If it’s looking like you can’t, you can start to make educated decisions about what work to cut and get a better idea of what you actually will deliver.
The criticism of the GP is that teams at his company would estimate story points differently depending on how much stress they wanted to take on and not based on the complexity of the work. This had the impact of the low stress teams not taking on ambitious work. Whereas teams that would take on ambitious work and attaching points to that work were working at unsustainable levels to meet targets.
In your Super Bowl example, you'd either get a team that would focus on doing the scrum activities but never deliver anything useful regardless of how many points it would take, or you'd get a burnt out team that's on the verge of flaming out. In either case "Story points" provide you with no predictive capacity even though predicting would provide value.
The predicting value is only per-team. If your team does 10 points per sprint, it won't deliver 20. If it does 100, it will.
But it's an important tenet of scrum that velocity is only meaningful in a single team[0], the root management failure in OP's case is comparing different teams.
[0] and teams cheat themselves too. I recall one advice early in my career that a velocity increase with no underlying process change was likely to mean.. that the team started to overestimate complexity, and one should understand what went wrong.
They don't help you do that, even though poor non-technical managers might think they do. That's why good software projects don't use them. I don't see any story ticket velocity points used in Linux kernel development.
You can't estimate non-trivial software, and if you are doing trivial predictable work, you should be automating it, not endlessly estimating it.
I didn't say I would "deliver" anything. It's done when it's done. You can't predict the outcome of a software project. Many of them fail and micromanagement makes them more likely to fail.
> You can't estimate non-trivial software, and if you are doing trivial predictable work, you should be automating it, not endlessly estimating it.
so if you automate trivial predictable work (for example by making a CRUD app generator), you're moving to non-trivial software territory with costs unknown (as you said, you can't estimate), potentially very high
Or you don't and end up making a non-functional website for the public sector for $100M. Software projects fail often, and not for the lack of trying, there is not yet any evidence that you can micromanage them into succeeding.
OP here. You are right, but the minimum point totals eliminates any benefits that can be achieved from scrum, it forces engineers to incentivize survival over project momentum. If a story is really a 3 pointer but I know that if I close 2 3 point stories in a week then I am pipped, suddenly those 3 point stories are 5 point stories.
On the teams that played fair, it was a mix of sr. and jr. and the sr. measuring that story at a 3 meant the jr. was working the weekend. Over and over again.
Note: On the happy team, we had almost no supervision, not even a scrum master. We just looked out for each other. That 3 point story often suddenly became an 8 as the end of the week approached and no one blinked. That team incidentally was the only one that consistently got good reviews from management.
What does "played fair" mean? Did this organsiation have a fixed definition of the value of a story point?
EDIT: The reason I ask is because when story points are used "correctly" their value is defined entirely relative to the previous output of the team which produced the estimate. Like, their purpose is to allow dev teams to do relative estimation (which is pretty easy to do), but also enable someone to produce absolute estimates based on the team's track record of delivery. Team says a story is a 5 pointer? Query previously delivered stories which the team also said were 5 points and if there's enough data you'll be able to forecast with reasonable certainty how long it will take them to deliver this new story. Used this way there's no "fair" value of a story point - it doesn't matter if one team uses point values in the range 0 - 1 while another uses point values in the range 1,000 - 1,000,000.
The whole thing breaks if you start comparing point values across teams, or say that 1 point is 1 day's work or whatever.
"The point of scrum is to provide employment for consultants and non-engineers"
I'm actually starting to believe this. I work for a very large company that switched to agile. We have agile / scrum coaches in pretty much every big meeting and I have yet to hear one say anything. I don't mean anything useful, I mean anything at all. They just sit there blinking. I have no idea what they do.
> But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns.
Maybe as-written but not really ever as-practiced.
They were splitting tickets to avoid being let go, not because they necessarily warranted it or comprised logically separate things. I'm pretty sure that's not how scrum is supposed to work, but if it is it doesn't sound good to me.
The ironic thing is that may have generated exactly the outcomes management wanted.
I’ve worked at places where it was more important for management to know what to expect than to achieve raw productivity towards a goal.
The people who were estimating in good faith may have assumed that management was acting in good faith. Whereas a lot of projects are created aspirationally or have artificially short deadlines to “motivate” people. The stress they incurred may have just been for the emotional satisfaction of a manager and not have provided any more value than that.
>Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week.
I read this as the teams that attempted to measure in good faith did a poor job at estimating. If management tells you that you are required to deliver 10 points per week, then 10 points should take you 40 hours with rare exception. Whatever other idea you had in your head of what 10 points "should" mean is simply incorrect.
Thats exactly what happened. People that tried to do it right, got punished as they ended up working weekends all the time. People that did as you suggest and went high, were stress free.
Measuring story points across the company is such a weird thing. The meaning of points depends on the team. Like you can decide to multiply all the feature costs by 10 from one sprint to another if you want to.
The only usage of points is to improve the predictability of the output of a team. It cannot be used to measure performance in an absolute way.
If performance metrics are built on points, it just ruins the meaning of points. There is no reason to be honest anymore.
Nice story. It's unfortunately really hard for higher management to see something like this. I guess it's on the middle manager to convince upper management of this.
Unfortunately in my current experience my manager is not at all like Tim.
Senior engineers in my knowledge and experience are all delivering on something relatively high impact while contributing massively to the team by occasional/often "pairing".
I've seen rare examples who don't "pair" but just deliver by themselves.
I've never seen an example where they don't deliver on anything (planning, design, architectures included) but only "pair" as their job every day.
You do realize that pairing is also delivering in everything you mentioned? Just because you hadn't the luck to experience this in your career so far doesn't invalidate this
Oh I had plenty of luck in my career, there are people who the entire team goes to when new/unknown/specific problems show up, and I happen to be one of them.
But I don't sit over someone's shoulder at all times. I only try to help when I'm needed, otherwise I'm knee deep in my own deliverables.
In orthodox agile environment planning, design and architecture might not result in any "story points".
Also these activities might not always result in a lot or any artifacts. E.g. being in a meeting, making sense of messy stream of requirements and using institutional knowledge to help set the right priorities on a project or prevent team from spending months on a dead end idea might not leave any paper trail at all.
Seniors are usually expected to do these things and also produce tangible artifacts. At the principle / architect level maybe you aren't producing code artifacts but you should easily be demonstrating 7+ figure impacts to the business from your efforts.
I agree that it seems like a weird distribution of time for someone senior. It's fine and good to mentor juniors or pair some of the time but I think that in general pairing is net less effective than two people working individually. Seniors certainly and usually team leads are expected to deliver some individual work product. You can definitely help make teammates more effective without spending all of your time on their shoulder.
Also: the business established a metric it wanted ICs to meet, the guy in the story refused to participate in it at all. At the very least, he's demonstrating resistance to following the expectations of leadership. He might be a good team player at the smallest scope, but great engineers can do that and simultaneously play along with management/biz interests.
(I'll also agree with the article that measuring "story points" or whatever is probably a bad metric, like most measures of software productivity.)
Too lazy to track down the exact company, but the author does link to Tim's LinkedIn. He has many titles as "Agile coach" and his lede is
>Enabling technology teams to operate at their full potential
Sounds like he is a very particular type of developer focused precisely on enabling teams in this manner.
-----
also, I can just post the obvious here but: he may be doing work but not tracking it. I've never been perfect at creating stories for every task I get, especially retroactive ones that pop up in the middle of the week.
The team being described here was one where all work was done paired. Senior engineers were never delivering by themselves. It sounds like you have experience of teams which are not like that, which makes comparisons ineffective.
The real reason Tim showed up as having zero productivity was because he always let his pair put their name on the ticket, and so get the credit for it. This is really a story about how things go wrong when a ticket tracker designed for solo work is used by a team which pairs.
I'm this kind of person most of the time and it really sucks come review time. I'm also a mentor type and that is also very hard to account for in most systems. It means I do an essential role that is seldom rewarded because there's no number associated with my meddling.
667 comments
[ 3.0 ms ] story [ 353 ms ] threadI dont see a downside to doing this.
It's the one used by all the major ones: airlines, auto manufacturers, and teachers. What institution do you know of that has a greater emphasis on measuring performance?
I'm sure most unions would love performance based pay where union reps decide what constitutes good performance. For some mysterious reason management is as keen on unions exercising their judgement as unions are on management deciding.
Where unions agree policies that treat members as interchangeable (e.g. age based pay) it is usually as a result of a compromise brooked with management who would love to have the latitude to give pay raises to scabs, kiss asses and spies.
The shape of the union is whatever the membership wants it to have.
At least programming has some verifiable realities that can be witnessed objectively by multiple observers. Not that such things are often used on "metrics", but they could be.
The quality of someone's management is hard to assess from outside, much less objectively verify. Has your manager increased or decreased your productivity today? Was it necessary that they do so for a larger goal you're not considering? Were they just power tripping?
Measuring is an aggressive act intended to invoke control that has a veneer of innocence.
That said I'm now wondering if there wouldn't be some metrics which might prove useful to workers either way.
Let me know if you find any downsides.
Anyway, management will of course argue that developers under them are incapable of seeing everything management does. After all, management's job is to shield developers from other managers, so if the developers think all the managers at the company are worthless, that's actually a sign of how well management did their job of shielding each other's teams from each other.
There are also plenty of successful companies and projects without management too. Basically every 1-to-5ish-man consulting shop has zero managers and some of those do wildly well. Some of the best indie games, produced by teams of 3 or 4, had zero dedicated management. Most open source projects have effectively 0 management.
Valve, famously, kept a flat organizational structure for a long time, and certainly was somewhat successful.
So, yes absolutely, administrative work now can finally be replaced, and we can free up all the tormented souls in these managerial positions to do something more meaningful with their lives.
These companies are even more stratified than before with the lumpenproletariat doing human-mechanized tasks while executives program their lives using software we write in exchange for the unbridled luxuries like the chance to own a roof over our head one day.
It's not exactly the future I wanted.
What a coincidence! Thats one of the first thoughts that crept into my head when code metrics started being used on me.
This "voyage of discovery" you've alluded to is exactly what I meant by no downsides.
If managers feels threatened by being measured by their employees after their employees start measuring them, well, that's also an interesting reflection is it not?
People at the top of the hierarchy probably do care about people at the bottom, but it's difficult to care about a large number of people as individuals, so they resort to metrics that probably models what's going on. Unfortunately, the metrics don't always work.
Instead of measuring and gaming numerical metrics, enforcing a particular culture might be a better way to go:
https://apenwarr.ca/log/20190926
No, you probably shouldn't be saying that:
https://en.wikipedia.org/wiki/Harry_Nyquist
https://en.wikipedia.org/wiki/Nyquist_frequency
> but what's stopping a dozen other things at least that useful from being part of the answer?
Because someone needs to act, and that's exactly what Nyquist did, in a very unobtrusive and non-confrontational manner.
> Because someone needs to act, and that's exactly what Nyquist did, in a very unobtrusive and non-confrontational manner
Seems like your headcanon. It reality they ate lunch together and passed ideas around.
I.e. there's no check or control on their output without lunch or breakfast with him, maybe it'd have been little different.
Engineering excellence is not a prerequisite to business success. Managers know this.
Why else many things any one of us could list from the computing business.
Woe is us. Five or ten years is not considered short term
> . I try to give more to the clients that pay more, or at least create something that I can reuse in the future, while making sure what I deliver is stable and not a big ball of spaghetti to make the next developer/engineer cry at night.
I am not sure about the "...who pay more". As I am currently woefully underpaid I am more sympathetic to that view than once I was, but, I still view myself as a professional, and I act with professional ethics.
Partly that means speaking up when I see a project going near the rocks. I do not make too much fuss, but I do say it out loud.
That has cost me plenty. Our industry is full of people who are very good at one thing or another, but do not know their limits.
Part of my "being professional" is knowing my own limits.
It is important to know what you can and can't get away with, and my clients don't pay the cost of the business I'm employed by making bad decisions. Where I am able to, I strive to provide a product that is better than the average, in the hopes that I've developed a solution that can possibly benefit the company or myself in the future in regards to software quality or speed (along with stability) of deployment.
I have heard of the Nyquist frequency, the nyquist limit, the nyquist sampling rate and the Shannon nyquist theorem.
As far as I know no other individual has had this many “things” named after him.
Note that the "Known for" section on his main page has 119 elements. But they're not all named after him.
https://en.wikipedia.org/wiki/List_of_things_named_after_Leo...
"In an effort to avoid naming everything after Euler, some discoveries and theorems are attributed to the first person to have proved them _after_ Euler."
I always remember as “questions are harder than answers”.
Woah. He has a huge list of "Known for"!
Good people amplifiers are domain/technical experts; Scrum Masters/Agile Coaches are neither.
At this point i think it is rather well established; eg. "Taskmasters" in - https://en.wikipedia.org/wiki/Bullshit_Jobs
And yes . . . I do code.
It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). Hence the Problem Domain and technologies used in the Solution Domain are what matter and everything else is ancillary. The Processes/Methodologies used are only useful in as much as they help us understand the problem domain better and map it to a specific solution. Thus the application of the former is informed by knowledge of the latter and cannot exist by itself. Hence the reason we have so many types/variations of Processes/Methodologies; there are some common principles but will always need to be adapted/customized to the problem and tools at hand.
This is what is the problem with modern-day Management/Leadership and eloquently pointed out by David Graeber(Bullshit Jobs - https://en.wikipedia.org/wiki/Bullshit_Jobs) and Jeffrey Pfeffer(Leadership BS - https://jeffreypfeffer.com/books/leadership-bs-fixing-workpl...).
I highly recommend reading this speech by David Packard (one of the founders of Silicon Valley via HP) to new Managers given in 1960 and note how relevant it is for all companies today - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-...
Relevant Excerpt:
Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.
I've had multiple Producers who "understand the work" of creating mobile games as a whole and understand how the team needs to work and interact to produce a result on time.
None of them could code a mobile game to save their life.
What your example is talking is a situation where a fresh off the press MBA is shoved in to a very specific field and they start just doing pure numbers and Excel management out of a management book without knowing how that specific industry operates.
Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
True. However, the relationship between them need not be a "Total Function" but definitely needs to be a "Partial Function" to a certain degree. You cannot be completely divorced from the "How" and hope to have a good "understanding" of the system.
>Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
This is precisely the point; domain/technical knowledge is needed to effectively Manage a project. This is independent of knowledge of techniques of Management. The problem today is that entire industries have been created out of thin air which posit that the latter is sufficient if one follows a certain process/methodology which is patently absurd.
No, I think at least in large part, you missed the point.
> It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever).
As I understood _Bullshit Jobs,_ "adding tangible value" to some business that doesn't actually add anything of actual (non-monetary) value to the world is bullshit. There are whole industries that make billions of dollars, but everyone who works in them is still doing a bullshit job. (I often think I do.)
From https://en.wikipedia.org/wiki/Bullshit_Jobs :
... as he describes, five types of entirely pointless jobs: ... 5. Taskmasters, who create extra work for those who do not need it, e.g., middle management, leadership professionals.
In companies, he concludes that the rise of service sector jobs owes less to economic need than to "managerial feudalism", in which employers need underlings in order to feel important and maintain competitive status and power.
From https://en.wikipedia.org/wiki/Bullshit_job :
Graeber also formulated the concept of bullshitization, where previously meaningful work turns into a bullshit job through corporatization, marketization or managerialism.
The best amplifier I've met was hired as a junior coder to my team and was paired with a couple of 10x coders on a project with a client who was "hands-on" and loved to micro-manage, having been a software developer themselves a long time ago.
The Amplifier's coding output wasn't that good, but the team as a whole was doing better than before so I investigated.
Turns out the 10x guys weren't that keen on communicating with ... well anyone outside of the team, much less with non-technical clients (or technical clients who loved micromanage). Both were your stereotypical cold pizza and warm cola coders with limited social skills. They could kinda sorta manage the meetings and emails directly from customers but didn't exactly relish it.
The junior hire was more like a 0.5x coder, but had ample social and organisation skills and worked extremely well as a liaison between the team and any external contacts they needed, taking over most "useless" meetings with the product owner and customer.
The junior coder ended up receiving some training and was "promoted" to a Scrum Master/Producer/Project Manager (the exact title escapes me) for the team. Everyone was happy and productive.
Your "Amplifier" is more like what is known as a "Field Applications Engineer" in the Embedded industry i.e. somebody with enough Domain/Technical/Marketing/Sales skills fulfilling a tangible need for the Business. They are more a "Business Process Optimizer" than a "People Amplifier"(a term i made up :-) who i define as somebody who can spark creativity/insights/viewpoints etc. which push others forward in their problem-solving endeavours. It is not merely removing hurdles/book-keeping/time management/liaisoning but an active role involving discussions/brainstorming/idea generation. This cannot be done without bringing some expertise to the table relevant to the problem at hand.
While I did go out to lunch with coworkers more often while working in the office it was almost exclusively with direct teammates, and other groups I occasionally saw where also on the same team.
Now that I'm fully remote, I will typically do a few "hacking sessions" over Zoom every week. Its much easier and more comfortable than standing over their shoulder in tiny cubes we used to have.
That said, especially now that i am fully remote, I've been trying and mostly failing to get developers especially across teams to talk and collaborate more. But its not too suprising: I was recently in a call and I was introduced to another developer who I replied, "Yeah, I know you. I was in the cube next to you for 2 years and on your team for 6 months."
Remote creates some new challenges, but its a culture thing, not a technology thing.
It's not the same as having lunch together but it is enjoyable and useful.
The answer is that I never was good at social things like inviting people to coffee.
But it doesn't help that we're taught to "protect" our time and avoid unnecessary calls and meetings. Presumably so we can write more lines of code, close more tickets, or earn more points like the story and other anecdotes here.
I think I may try something new in my calendar. Worst case I'll end up sitting in front of my computer alone with a block for the next hour and nothing to do but work on all those things I need to do anyways.
But that is balanced by the threat of people trying to use metrics to measure developer productivity. It doesn't seem to be possible, any metric falls apart. If people are focusing on a metric, the greats aren't going to be leading any more. It'll be some junior who has misunderstood the system and has accidentally trained themselves to game metrics.
Metrics do not drive good software. Repeatable processes love metrics. Repeatable software suggests bad development practices because that is a big hint of a library or bigger opportunity that nobody on the ground properly identified.
...when they're actually hands-on-keyboard writing software. The best programmers I know write as little code as possible.
Product team: Hmm, we need to do a thing that looks very complex and difficult.
Senior dev: I'll start making a project plan and story breakdown.
Very senior dev: That sounds like a special case of a thing we already have. That should take about an hour.
Of course that's a generalization, but I think the trend holds. The most illustrative metric for the best engineers wouldn't be "lines written" but "lines avoided".
I don’t mean they use the latest fashion library, I mean the amount of code they type is less simply because they understand the problem and know how to write a minimal solution.
This makes their code easy to read and therefore easier to debug.
It’s worth noting that the less you type, the fewer bugs you’ll create.
To be fair, this is often due to the coder having significant experience.
Red flag!
A "very senior dev" will not be handing out "1 hour" estimates to a product team. An hour of what? Billable hours? Wall-clock time? It's just not the right framing. You will notice a good senior dev will be incredibly cautious about any commitment and not hand out "ego estimates" like one hour. They will make commitments that they can keep and it will be terms of releases.
They will have experienced a decade of "one hour jobs" that have exploded so they know that even the error bars on a slam dunk 1 hour of butt-in-seat time means it's not a 1 hour estimate. An hour of butt-in-seat coding time is not a 1 hour of employee time - they've got that training course, those interviews, they need to support that thing, oh the presentation, the intern to look after. That feature you are copying? What is it copy-paste or some refactor generalisation? Measure that shit in weeks. Oh and there are 6 feature branches overlapping that area already. You also have a policy to improve the tech debt of this crusty code. There is also the documentation, training material, translations, the test suite, code review, the issue tracker... But hey, you can do it, you are x10, you boot up your machine and... your IDE is crashing because of some security update. Doesn't count in that one hour eh?!
That's not even the main issue, odds are the first over the shoulder demo of this new feature will be just the start of eliciting the real requirements.
If I say 1 hour, I mean that I know exactly which knob needs to be twiddled, perhaps because I wrote it in the first place, and that there'll be a pull request ready for review an hour from now.
That's clearly not always possible. Sometimes it is. If I say that it is, then I can deliver it.
> Sometimes it is.
What's the worst case of the other times? These "one hour" estimates are the golden path, nothing goes wrong, minimum. It's not the average of horror shows or an amortisation all the related support work required to sustain efficient development over time. They are often too coding-focused and ignore the level of interpersonal work to agree and sign off features or to change code in collaboration with others. Talking through a demo can take more time than the code.
Not if they game the metrics, as a way to force change.
A classic example of an exceptional programmer doing worse on a (bad) metric is at https://www.folklore.org/StoryView.py?story=Negative_2000_Li... , titled "-2000 Lines Of Code".
"Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. ... Bill Atkinson ... thought that lines of code was a silly measure of software productivity. ... [He] made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code. ... when it was time to fill out the management form ... he thought about it for a second, and then wrote in the number: -2000. ... after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied."
Ultimately the best way of measuring programmer productivity is by the assessments of the programmers on the team. This isn't as easy as it seems. For example, I once worked on a team where the best Heroku guy just had the absolute wrong idea about "easily understandable python code" since he would prefer to raise and catch an exception instead of rely on a built-in to test attribute existence or type compatibility. But nobody could get around large scale Heroku deployments like this guy. The juniors understand this nuance less well than seniors do, but even so, it does sorta come out in the wash. Your team does know its best people and they're usually happy to say it in a private one on one.
The funny example is that the hasattr built-in just tries to getattr, and then catches the exception to tell if it has the attribute.
https://docs.python.org/3/glossary.html#term-EAFP comments:
> Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C.
and there are any number of essays on the topic, like (random DDG search) https://programmingduck.com/articles/lbyl-eafp .
If there are situations where you have no choice but to drive without airbags, those are holes in safety.
Essentially if you have to have runtime checks to prevent the program from full on crashing those are holes. Not everything is checkable with static checks but the way to go is to move as much of your code away from runtime checks as much as possible.
So for opening a file for example, using try/except instead of checking if the file exist and is readable first.
Both achieve the same results but the first is more "pythonic".
My point is that this way of writing code is not at all incompatible with using a type checker for said code.
I'm saying "incompatible" isn't even a relevant concept here. Here's an analogy:
You're telling me that running with shoes is compatible with running without shoes thus I can run with one shoe on one foot and the other foot is barefoot.
The goal is to objectively put shoes on both feet. Sometimes you're missing a shoe so you have no choice. But this has nothing to do with "compatibility" it's a completely different thing.
We are getting a bit into pedantic territory here, but THAT was my point and I am simply clarifying it because you MISSED the point.
The fact that the language doesn't have your back means you need to be more careful about types, not less. The type of the arguments is a function precondition. It's the callee's responsibility to document preconditions and ideally recover cleanly from a violation, but the caller's responsibility to ensure preconditions are met. Illegal states should be caught early, not allowed to percolate until an exception is thrown.
I don't much care if what I just wrote is "Pythonic" or not. I don't think too much careful design up front is responsible for every Python codebase I've ever seen reading like Finnegan's Wake.
I dunno. I don’t love Python for big projects either. If we want to go around and tell all the people using this very popular language to stop shipping their successful products because they look messy to us, I’ll happily take the second shift (after you), haha.
So if you have a manager who is a dialed-in coder who's going to keep updating the jira-point formula based on spending more than 1 hour a day reading code, and keep tuning it around the ever-more creative loopholes engineers employ, then yes, you may end up with a workable system. But never yet in my long career have I seen that.
The story includes a part where they dropped the crappy metric and changed to a better one.
Maybe ... Productivity itself is difficult to define. Different people will value aspects of the work differently
At one Internet Advertising company I worked for, the founder had written most of the original code. Written in the late 1990s, it was Perl, JavaScript, HTML, and SQL jumbled together. Completely ignoring the notion of 'separation of concerns'. Huge amount of code duplication. Source code control? Phhht! Nary a test in sight. Ran programs as root to work around permission problems. Self modifying code ... you betcha. He worked right on the production servers. He could and would push out a feature the same day a customer asked for it. VERY quick to make the customers happy. The company was being bought out at the time I came on board. Pocketed his millions, headed down the road, yay for him.
My own take is that the company would never have 'made it', if a software team had been hired to 'do it properly'.
After his departure, as we rewrote our code base to 'professional' standards, much time was spent refactoring that produced few or no new features. How productive was that? A very complex question.
As a digression, I sometimes found his original code easier to maintain that the stuff done 'the right way' because there WAS no 'separation of concerns'. I didn't have to hunt in a different part of the source tree for where something was done. It was all 'right there'. YMMV.
In the end, 'productivity' is way more subjective that we'd like.
This is my take too as I have gained experience. The way I did code from the get go, was the overall best way. Long function that did the stuff one thing at a time. Like no functions called from different parts of the call tree. I breeze to debug and understand or modify.
BREAKING NEWS: Pair programming improves software quality, more at 5!
But you can't deny that it's an amazing tool to open silos in terms of knowledge. I wish people would be more open to it, because I've never been able to get someone up to speed faster with a tool or codebase, than with pair programming. And vice versa too. If you're the person that knows less about the topic, pair programming with a senior is like a one on one tutoring session with a really skilled instructor. It's worth the time in gold imo.
Also to say it couldn't happen at tech companies is pretty bold. There's nothing special about tech companies. They can hire incompetent managers just as well as other companies.
Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently write 5000+ lines per code per week, regardless of how many features they actually ship and how many bugs they introduce.
As a team lead and engineer who has managed some complex projects, the idea of someone writing over 2000 lines of code per week terrifies me... That's over 100K lines of code a year. Think of the unnecessary complexity. There is a very good chance that the same feature set could have been implemented with just 10K lines of code, less buggy and in half the time though that would only amount to 380 lines of code per week! Management won't like that.
I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code.
Because lins of code churned out is not and has never been a good measure of productivity.
That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem.
Which is basically the entire point of the article.
Why not? Peer feedback is a prime component of most performance/rewards discussions at companies. Work outside of points is certainly not a new concept. A manager's job is to distill this information amongst others to their own management chain at the right time.
> We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways.
Bob's time isn't unlimited. There are surely instances where he was helping out Joe, Suzie, Darren, and James and had no time for Alice.
Based on your other comment, you seem to think someone being an unblocker/idea generator/dev lead is a "low performer" who weighs the team down. That's just fundamentally wrong.
> The people that can do this without needing Bobs around are the people that will be rewarded.
Unicorns are few and far between, but sure, you do you.
Also, solving the same problem with less code is a lot more valuable than many think. Not only are there fewer code paths to test, the system probably has fewer unnecessary constraints and edge cases to consider. How do you account for negative LoC?
It will take me far longer to come up with the correct 100 lines that is both maintainable and can be worked on by others down the line.
I can pad my lines of code in seconds if I wanted to before pushing the changes. That padding provides no business value and might even introduce bugs.
And how do you handle refactoring? If I come in and refactor everyone else's shitty padding by combining helpers and optimizing code, I'll have negative lines of code. Am I an unproductive worker?
Sure, most code is not some complex algorithm but lines of code is a stupid metric that is not representative of the work done and can be gamed by anyone knowing what they're doing.
It's better to have tests more sensitive to failure, like integration or regression tests.
The key there is caching your results. Don’t run unit tests for code that hasn’t changed.
They still serve the important purpose of checking validity of the code under test though, so if they do get modified downstream at some point and they fail you then know the changes aren’t conforming to expectations of the system.
This of course assumes people aren’t writing highly coupled tests and that is more rare than I wish it to be
It's the team that creates that kind of opportunity for feedback though. If the team has dysfunctions like rejecting deeper discussion or not working beyond jira tickets or checking out at meetings, etc. then it's not going to work. Someone that's good at that kind of supporting discussion will feel push back when fostering those discussions so it will fall off over time.
The teams that do the best work and are the most fun to be on can host those types of discussions though, even remotely. It's worth experiencing if you haven't!
I assume you mean the thoughtful person whose probing questions unlock and unblock everyone else.
Lunchtime conversation is only one enabler of this.
I suspect the person is Hamming, as he makes reference to this in his book The Art of Doing Science and Engineering.
This aspect of what it takes to be a Hamming is curiosity about what other people are doing; you can track this by reading shipped emails or lurking in slack channels, then reaching out individually to the people/teams involved when you wonder about something.
Hamming was intentional about doing this at lunch. The magic isn't lunch, it is in intentionally seeking the information and then acting on it.
You do need to cultivate a culture in the team of people being willing to lower their guard and ask questions though. And I think the key to this is just staying humble so people feel comfortable approaching you.
It has become taboo to say things like "This code is too tightly coupled", "You don't need to add an external dependency for that", "The inputs to those methods are too complicated; your components are micromanaging each others' state", "You're violating separation of concerns", "The cyclomatic complexity of this code is too high; you could simplify all your if-else statements"... When it's not my company, it's impossible to dismiss code when it works right now, even though it is likely to break later.
Warning: it looks like you’re trying to pack too much crap into a single PR and your peers are unlikely to understand what they are accepting.
"This change is hard for me to read and understand"
or
"This is a large PR, and it may be difficult for me to schedule time to review it. Can it be split up into a series?"
I also configure linters and code quality tools to automatically flag some of the more egregious problems.
I'm 33 but I feel like I already have to make an effort to avoid the dinosaur label. I disagree with a lot of modern tech trends but I simply cannot express my view about them even though I could explain the problems very clearly and logically and can provide far better and simpler alternatives. Unfortunately, hype does not yield to reasoning... And sometimes, you're too far into the tech debt and it doesn't make financial sense to rewrite.
My current reality is that I'm a 33 year old working with 20 year olds who think they're geniuses who are going to take over the world in 5 years; from that viewpoint, I'm essentially a failed engineer because I didn't build a Facebook, Uber or AirBnB even though I had 10 years to do it.
Believe it or not, I consulted at one place where the manager decided I was the problem because I was consistently assessing problem code and team processes in similar ways. She asserted that "everyone else understood", even when they plainly didn't understand but where just going through the motions.
Said manager had a number of other issues as well. Worst gig I can recall having in the last couple of decades.
Edit to add: in 1:1s with the manager I was more direct. About the best I can say about that is "at least I tried".
The last greenfield project which I managed from scratch, we didn't have this problem because all developers shared the same mental model of what we were building before we wrote any code. We had a lot of discussions beforehand to get to this shared understanding. There was literally not a single PR which surprised me throughout the entire project and I'm sure none of my PRs were a surprise to any of my team mates either. There was plenty of disagreement throughout but it was always fully resolved through discussion before we started coding each major feature.
I've found that kind of feedback to be useful actually. And when giving similar feedback it is received better with a small change in wording to make it more about the code and not the person. Even if that is the intention the wording does matter. For example:
"An external dependency isn't needed here, try implementing with XYZ instead." "Split this function into x and y for better separation of concerns"
Removing the "you" removes some resistance to receiving the message .
I’ve become fond of mostly asking questions.
I wonder if we could avoid this dependency? Maybe [idea] would work?
Can you see a way to separate the X concern into a module?
Can we split this function up a bit so the nesting won’t be so deep? Would this loop body make a good standalone function?
Without going into specifics, there was a case where I reviewed a PR, asking "this isn't usually how people do file operations, are you sure this is really fine?" To address my concerns, they even wrote a specific test program to "prove" that there weren't any problems with the code. I reluctantly approved the PR since I couldn't just ask them to rewrite the whole patch due to just a hunch.
Lo and behold, after a kernel upgrade and file system change, that weird piece of code caused a multi-week panic for the whole team. The extra funny thing is that the test program above made it trivial to confirm and reproduce the issue once we identified this was the cause.
The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.
When you do things right, people won't be sure you've done anything at all.
He did experiments where he would have workers shovel piles of ash from one side of a line to the next, giving them a new shovel size each day. Found that the ideal shovel size holds 21 pounds [1].
The ideological assumption of his work is that management exclusively does the thinking and the workers exclusively do the doing. This falls apart when the workers have unique knowledge and insight that management does not have.
[1] https://www.mentalfloss.com/article/63341/frederick-winslow-...
AKA every time.
AFAIK, Taylor himself wasn't nearly as radical about doing measurements and only acting on them nor about managers deciding everything and not listening to the workers as Taylorism preaches. His work was one of the many, many management theories that was completely modified to appeal to incompetent power-hungry wannabe dictators (and yet blamed on the person proposing the original theory).
He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable.
That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.
And I learned that doing it my way will get me fired because the manager has asked to do faster.
The way I have learned to get around this is by making the manager publicly document the request to go faster. If they don't document, I don't see or act on it. Once they document it, I happily go faster and let it all crash and burn. Then when they inevitably try to blame me, I point at the public documentation of the request to go faster and let the blame fall on the person responsible.
if time is the only actual concern for the project's success, a good approach is to explicitly re-scope the feature list and start asking managers things like:
"do we really need feature X to release? can feature Y wait until after beta? did the request for feature Z come from a user or a stakeholder?"
document all that too of course ;) but then at least there is a chance for safety _and_ success
Yes the project will fail. But if my manager only cares about speed, why should I care about anything more? Why should an engineer be responsible for a manager's poor decisions?
Because the corporate hierarchy demands it. Front-line workers are expendable, much like front-line soldiers. Corporations are not democracies, and neither are militaries.
If your job is to write and commit code, you are the corporate equivalent of infantry. In short: a grunt.
And if I am being treated as a grunt, I will act like a grunt aka I don't care more than my bosses. I will even abandon ship at the sign of incompetence and point out the incompetence to others.
Regardless, it’s an important life skill to learn that it’s generally not enough to ask people to do what you want, you need them to actually “buy in” to what you want, and then they’ll actually care enough to at least try make it happen.
This applies to managers and their employees, or also when trying to get on the ground employees to adopt a product initially sold to their manager/execs.
I don't feel the need to get "buy in" for bad faith managers.
An overly broad statement which, my experience, is not true. Managers come in many shapes.
Although, I suppose ironically, if you act in bad faith as a response to this perception, then I think that perception will quickly become true.
If the project fails, and the manager tries to blame it on you, they are de facto acting out of bad faith given the request. Documenting it just identifies this. If the project succeeds or fails, but no one blames you, then the documented request is just there for the record.
If we don’t know if anyone will want the product, the quality of the product is less valuable than validation of product market fit.
Later, I care much more about avoiding accidental complexity and having a great technical foundation.
This sounds like an improvement over the opposite, a code base that is rarely touched and uses eol frameworks. Software is a living thing and if you don’t act as a ruthless gardener you wind up a museum curator with 1990s DEC hardware running in the 2010’s.
The right balance of staying current and not reinventing the wheel is not trivial.
And yes, 10 years is quite possible these days. Besides the infamous Javascript framework churn, things are moving quite a bit slower in recent years.
In part, this is due to the risks inherent to change have been spread out over 10 years instead of backloaded to the end.
Practicing mitigating risks by proactively taking them has value of its own. The parable of ergodic cakes shows this.[0] What % of cakes will fail if 10 people each bake one, versus one person baking 10 over time?
https://luca-dellanna.com/what-is-ergodicity/
reactjs came out in 2013, so it meets the 10y metric, but it has some internal churn, such as classes, hooks, etc
There are PDP-11s running nuclear plants today with support contracts to keep them running until 2050.
PDP-11s.
Indeed, business people do not typically model depreciation curves for software as they should. That doesn't mean that the plant control system becomes less valuable (the value is tied to the operation of the plant, probably for the lifetime of the plant), but in many other situations it does mean that.
I'm not going to drive off a cliff just because the OKR tells me there's actually a road there but I wonder about some people...
This is my company. Engineer skills, tech-debt, teamwork, camaraderie don't matter. Do as the management says, in the time they've promised to others or else....
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role is sound.
Now TLM (Tech Lead + Manager), however......there's a role that's set up for failure. Be a manager but be judged entirely on your technical contributions.
Any meaningful contribution or engineering is extra credit.
If you are immature or competitive, you cease being a force multiplier to be a morale destroyer.
If you are more of a domain expert than your Product Managers, you will spend your time fighting and refining tasks to build features the right way.
If you don't have enough time to code, you'll go obsolete.
Where I disagree is with the idea of fighting with product owners. If there's a disagreement around approach or tech choices that's a sign we don't have enough information. Fighting or refining won't solve that. It's a signal that we need to do more discovery work and understand the problem better.
The problem is not needing discovery work or understanding the problem. The problem is when the Tech Lead is the one who's providing all the data for that discovery, or helping them understand the problem better, because of lack of expertise of PO/PM. Or having to push back because of incomplete knowledge.
If there is lack of information or incorrect information, POs should be able to get that information themselves. If a TL is the sole source of that info, then it becomes an issue.
IME this is very common. And it takes too much time of a Tech Lead's day.
If you are more of a domain expert than the product managers, argue for the product managers to be fired - they serve no purpose.
This is a strong statement. There are both people who are writing throwaway code and people who are writing essential code that match the description.
And one will never get to be the latter part without going through a phase where they are doing the first.
The parent comment doesn't contest this. I think it's about the throwaway code author being valued more than the other.
Managers love metrics. There's nothing wrong with metrics, of course. It's when metrics become targets that things fall apart.
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
What managers care about this at all?
You know, most companies.
One sign I see if a healthy workplace is one that tracks bugs and QA issues downstream against the same unit of work.
You quickly get a sense for what teams and even individuals are introducing the most bugs and issues.
If you can close tickets fast and your bug rate is low: that’s key, but I have found often that the people introducing the most bugs and issues into the codebase that others have to spend time dealing with are those that seemingly close their tickets rapidly every sprint
https://en.m.wikipedia.org/wiki/Carry_On_at_Your_Convenience
I am not against Unionizing "per se" but the role of Unions has never been "tell the management how to run their business". There has been some cases of (smallish) company being "acquired" by their own workforce, and the Unions might have helped with formalizing the deal, but this is rare, and anyway happens only when the company goes bankrupt or decides to shut down.
So I do not understand exactly what you mean here.
A Union can organize and sustain a strike. But they cannot "toss leadership out". Not the CEO, the Board or any manager at any level.
They could theorethically "blackmail" a company saying "strike will not end until X is fired" where X is a PM or manager or whatever but I never really heard of anyone trying this tactic, not to say actually succeed...
Some of that is indeed earned by the businesses reputation, but ultimately this is what I think spurred the decline of union membership in the US because businesses don’t get a lot if any value out of having a union around and the organized workers often find the benefits stagnant after some time
https://news.gallup.com/poll/398303/approval-labor-unions-hi...
I see it as very much a union-by-union thing, much like you would an employer.
Now, some programmers may be able to negotiate good terms for themselves, but the vast majority of that stage is simply how silver your tongue is. Why should you be paid better because you got a better charisma roll with the interviewer? I would want my coworkers to be paid the same as me for the same experience. A senior with 10 years in the field, naturally, would be paid much more.
It's strange you say developers can negotiate, when there've been quite a few layoffs as of late and we see plenty of stories of people having trouble staying in tech. Which is it? The only thing that can give you credible sway is learning rarer or more in-demand skills, and putting together projects that show you understand how to use them. And for how long will that last? A union is a lot harder to fight than an individual.
But yes, there are bad unions. If they're as bad as your alleged blue collar friends say, let's name them! Sometimes their politics or dues or seniority system sucks. Those systems deserve to be put on blast.
But strangely, no unions listed in your comment as bad.
I don't consider charisma very much because I connect it to dishonesty. If someone's put a lot of effort into coming across as charismatic, it means they have considerable skill in psychological and social manipulation. I would value that in a salesman, where it makes sense. Otherwise it's just masking 2.0.
The primary concerns in an interview should be "can you do the job" and "can we bear to work with you". The rest can be worked with.
Its not fun to lose your job, but that can be better than being stuck just getting by at a company where your work isnt appreciated.
A significant part of my personal code review process, is going back through my code, and factoring out complexity. It takes time and humility, but is very much, in my opinion, worth it.
Documenting my code is a trick that helps. When I am writing why I did something, I sometimes reflect, and say to myself "Didn't I just do this a few lines back?"
My code tends to be complex, by necessity, but it should be no more complex than absolutely needed.
A big, big tool for that, is OOP inheritance, which is considered "bad coder" smell, these days.
Is it? I’d agree that there’s increasing awareness of the limitations of OOP, and I’d agree that using inheritance excessively can be one of the limiting factors, but I don’t think I’ve ever personally seen anyone criticised or penalised for using inheritance appropriately.
I have run into folks that don't understand polymorphism. It seems that it is not even being taught.
Old Boomer Yells at Sky
(Exceptions exist, of course, like libraries inherently dealing with reflection)
One thing that geeks love doing, is telling other geeks they are bad at what they do. It gets a bit grating, but I’ve come to the realization that I need be true to myself, because it’s a losing proposition, hanging my self-respect on the opinions of others.
I do what I do, and get the results I get. I don’t spend much time, worrying about how I compare to others.
One of the benefits of working at the direction of my own muse.
That should make you even better equipped to design simple interfaces that require as little depth of understanding as possible from the next person.
Similarly I've happily spent my couple of years with functional purity and higher-level types in academic languages - function signatures sometimes orders of magnitude longer than the implementation itself - yet I dip into those depths only as necessary and try to keep my TypeScript interfaces as "stupid" as I can get away with without compromising on semantics. Enums are too fancy for me. I try to keep state at minimum but there's a 'let' every few thousand lines or so.
And all that venturing into lower-level concurrent C++, agent systems, parallel programming, erlang? You ain't gonna know about any of that looking at my concurrent Rust.
> One of the benefits of working at the direction of my own muse.
Oh, well, what I'm writing above is from the point of code meant for collaboration - either open source or professionally. If you're coding for yourself only, or in academia, by all means stop trying to please the crowd and start cranking out some poetry!
I write code that I want to see in a year.
You can see my documentation philosophy in this treatise: https://littlegreenviper.com/miscellany/leaving-a-legacy/
I’ve also seen composition go sideways too.
Sometimes it feels like nobody takes software engineering seriously anymore, if I’m being honest
I never warmed to that. In my experience, it resulted in unholy messes.
“Produce a procedure documentation” gets keyword fulfilled into “here is a document with some steps”, instead of “here is a procedure we wrote, used spelling and grammar checker upon [I’m still shocked so few take the few seconds to correct as they go], run through an automated editor, then iterated through random people from the user population until someone who never saw it before accomplishes the procedure without assistance”.
Some startups succeed because they’re forced into conscientiously thinking through these ramifications in just the right contexts because they’re so close to the coal face. It is also possible to overdo this in the wrong context and end up bikeshedding.
Edit: Take rock stars 3000 lines of code a week and divide by one rock star + six experienced developers now doing nothing but bug fixes and it doesn't seem so super.
Not everywhere. I’ve casually suggested five big changes to the startup I’m currently working for that others ran with. I’m proud that my ideas even make sense, and my reward is that others come to me for leadership. I would get more glory if I had also carried them out. But I’d rather do the things that others can’t, than what shines the most.
> 2000 lines of code per week terrifies me... That's over 100K lines of code a year
That would be incredible (and scary). But productive people I’ve seen the contributor metrics for who write vastly more than they read, still have a number of deleted lines growing with their added lines in some proportion.
There is a style of less re-use, more copy-pasting that just grows faster but also needs constant refactoring in trivial ways.
I've got a colleague like that. It's all good and management praises him, but this is a time ticking bomb. When he leaves, someone will have to maintain that code.
Or I could elaborate, expound, simplify, and expand my solution.
It depends what I’m getting paid for.
If I’m getting paid for lines of code, guess who’s going to re-implement functions that could have been a single line of code?
Why bother writing a loop function when I could just copy-paste the same code as many times as needed?
Turning one line of code into 3,000 - easy.
Turning 1,000 lines into 100 - that’s when you know you’re working with a professional.
When a market is competitive, the things that matter are roughly: hard work, candlepower, and optics/neurotypicality/maneuver in that order.
When a market is fairly sewn up that order becomes roughly: optics, candlepower, ethical flexibility, hard work in that order.
The hard-ass nerds who don’t give a shit about corporate culture du jour are treated like royalty when someone might fuck your business up.
While “purged” is a strong word, I take your meaning, and whatever we want to call it, it happens when competition is largely pro-forma.
Human beings will do anything to avoid selecting on merit except lose. That’s just human nature. Being mad about it is like yelling at the wind, but compared to even a decade ago, I’m not sure how high I’d be holding my head in today’s competitive landscape for high-prestige achievement.
Well I do know why just don't agree with the principle of seeing how much the company can get out of a developer in x hours.
How on earth, you might wonder, did we ship software that worked?
I then saw all these things come down the pike one after another during the last half of my career.
Clearly to me every one of these benefit management who found themselves apparently unable to function without numbers, graphs, data of some sort. It has been a very obvious (to me) power struggle: management trying to get the upper hand and wrest any and all power (and autonomy, and decision making) from engineering.
It has been sad to me to have heard some new engineers come on board who like these things. It's just as well I retired when I did: it's probably me that is the odd man out now.
To my understanding even IBM in the 70s had stupid ways of measuring productivity (KLOCs?).
They did all that by walking around, chatting with everyone, helping devs, assigning tasks depending on the expertise level, sometimes doing boring work (like manual testing) to help devs, etc.
Of course, if a manager that has to handle Jira and Scrum meetings all day, then it gets difficult to do that.
Apple very much was engineer-driven when I began. That changed when Steve Jobs returned.
It's obviously cost cutting niggling and get-it-out-the-door histrionics causing this chaos. There is significant impact to longevity and durability, and required maintenance. Very wasteful from a global warming perspective.
Watch out for these late model ICE engines...do your research. If it's "newly redesigned!" step back and dig in.
Management though use the "percent coverage by unit tests" as some sort of safe/buggy software metric.
Management at one team I worked on was pushing for minimal 95% coverage with unit tests. I thought it was odd that they were so singularly focused on this issue. The impression I had was a that they felt that if you have full code coverage with unit tests, and the test pass — you can lay off the QA team because you are assured that you are shipping perfect software.
They are going to manage risk of low quality with risk of wrong product.
Like, for someone in tier 1 / tier 2 helpdesk, or the regular developer pushing relatively normal tickets through, simple ticket or story throughput is one indicator of productivity. As long as you pair it with some success measurement, like re-reports from people within a short time, or work caused by the implementation. Or just feedback from the rest. Someone has to put down code to make the feature work in the end.
But this changes when you get more specialized and overall more experienced. If we bring a new technology into the team, my productivity based on the first metric will drop to zero. I'll be busy supporting other people. Or, the incidents on my desk will be far more weird ones. Other people get clear click paths and an exception. I had to debug JVM crashes due to faulty hardware. That took a bit longer than an afternoon in a debugger and adding an if-statement, if I may embellish a bit.
But that's why soft skills become important. It's concerning how little that manager knows about his team. But it's also concerning how Tim didn't make sure his manager knows what's going on. For example if we're bringing in new tech, I'm informing superiors first that I'll prioritize support of team-members with the new tech just below business critical incidents and I most likely won't do any regular work for some time.
"OK, last sprint the team did 150 points, so we should do 160 points this sprint."
The funny thing is that point estimates just went up to compensate for productivity gain demands. "More productivity" yay!
Maybe best as well because you quickly know to pack things up and look for a new job.
I’ve also met a lot of project managers who are there because they’re incompetent. They lean heavily on “agile” and “best practices” and say moronic stuff like, “can you show me how many lines of code each developer has added this month?” (this happened to me. I fought it hard, explaining that it’s not a meaningful metric. I showed him a month that I wrote -1500 lines of code).
I feel like I could say the same about managers, coders, executives. The incompetent exist everywhere and they lean heavily on bureaucracy to protect their existence.
I do not like people who do this. just tell me the answer. this is such a gigantic waste of everyone's time. you figured something out months/years ago, great for you. give it to me NOW, so I can get on with my day. if we BOTH run into something unknown, we can tackle it together. but dont force me to go through the same painful learning process you went through. YOU suffered, because at the time no one knew how to do whatever it was. now that someone knows (you), your job should be to spread that knowledge across the business as quickly as possible, not hoard it to yourself until someone is deemed "worthy" of knowing it.
Your situation is a waste of time where no one grows. The article is describing growing skills which is a net productivity benefit.
You're not going to learn from being handed an answer on a silver platter.
You'll implement it, get on with your day, and not at all think about why the answer is what it is.
this is an incorrect assumption. some people (like me) have an analytical mind. if I am given an answer, I will usually reverse it back to the question, so that I understand how it came about. or I will ask follow up questions until I have that understanding.
all this method is doing is forcing multiple people to go through the discovery process, when all that should be needed is for one person to do so. its a waste of business resources. person A can share with person B, then person B can go on to make their own discoveries. we dont need to force every employee to discover EVERYTHING on their own. thats just a huge waste of time. it would be like forcing everyone to discover Pythagorean theorem on their own, instead of giving them that tool and letting them use it to create other stuff.
> thats just a huge waste of time.
Instilling knowledge and discovery rather than rote completion of work based on others' ideas is far from a "waste of time" for people who actually understand the learning process. Growth is generally desired in the business world, even if it results in a short term hit.
Someone who makes a comment like this, isn't arguing in good faith, or even intelligently. So I will give this comment the respect it deserves: none.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
I'd personally find someone shadowing me and asking questions super annoying.
I don't think this would work with all teams, the takeaway I got from the article is about artificial metrics.
You can even add some prestidigitation by having them take 30 seconds to Google it and your name comes up. Play it off as a joke and now everyone has a little smirk/chuckle over it.
Now they know you have a good personality and can tell a funny joke about yourself. Goes a long way to putting you in that “I can work with this person” category.
Also, if they can’t appreciate the joke, that’s an easy red flag for you that you probably don’t ever want to work for that team.
"According to a 2018 CareerBuilder survey, 70% of employers check out applicants’ profiles as part of their screening process, and 54% have rejected applicants because of what they found."
I'm basing this on real world experience.
HR's job, like legal, or many other departments, is to facilitate what you actually do which in this case means work like chasing references and ensuring the candidates have somebody who can answer stupid logistics questions without bothering the interviewer, not figuring out who is the best fit for any particular job, that's the job of the people making the hiring decision.
Maybe if you're hiring fifty people to stand outside in the rain holding signs you can let HR pick who gets a job. Picking software engineers, especially if you actually care whether they're any good, is not the purpose of an HR department.
What I said was different. How many CVs should we eliminate before calling people back for the two openings? What if the pile is 500 CVs? Call all of them? I guess you stop coding for the next two months and that's ok? Or maybe you let HR help you sort the CVs by priority.
> who have no idea what they're doing
I've worked with some very talented HR people. Maybe you haven't been so lucky.
> HR's job, like legal, or many other departments, is to facilitate what you actually do which in this case means work like chasing references and ensuring the candidates have somebody who can answer stupid logistics questions without bothering the interviewer.
HR does more than facilitate. They protect the company from legal threats, just as one example. In the case of needing to trim down a huge stack of applicants to an actually manageable stack, then HR will do things like search the internet for people's reputation. If you think that's not their job, that doesn't change the fact that they are going to do it anyway. HR very often has a say in candidate fit. Especially if HR is responsible for company culture, as is often the case these days.
> Picking software engineers, especially if you actually care whether they're any good, is not the purpose of an HR department.
At most companies the HR department is pretty involved in the hiring process no matter what the position is. At smaller companies maybe less so.
> I've worked with some very talented HR people.
No doubt, since apparently you expect worse than useless it's likely hard not to exceed your expectations. What a buffoon.
You've offered no alternatives other than your schoolboy insults.
Sometimes we need to pay rent and deal with obnoxious HR departments.
Communication skills. Week 1 Tim could’ve brought up the issue of overall developer productivity with his manager and his manager would’ve at least been aware that Tim wasn’t just playing Minecraft all day.
If you aren’t communicating what you’re working on, it’s hard to get credit or recognition. And it’s not an ego or bragging thing: It’s just fundamental team communication.
For example, there may have been constraints that the manager knew about that sheer velocity was key for some reason. Or maybe the manager disagreed that Tim was adding enough value floating around all day. Who knows. But if Tim and his manager were in open communication, at a minimum there wouldn’t be confusion so great that a good engineer almost got shit-canned.
Pretty clickbaity title. This isn't a story about a bad programmer, it's a story about a bad metric, and an even worse manager who followed it blindly
The clickbait is made so that this document can be shared with a future shitty manager. If you send them a link titled "The Worst Manager" - I assure you their first reaction will be to figure out how to get rid of you.
Managers are the bane of this industry and sadly, engineers have to spend an immense amount of time dancing around shit managers.
Good. I hope it made you read the article and learn from it.
Yes it's a bad metric but so many engineers (not just managers) fail to understand that.
And apparently has zero idea of the team's internal working patterns.
I've worked with people like that, who were pretty bad individually, but brilliant when part of the right team.
Writing code and directly enabling the productivity of others who are writing code are different skillsets.
Obviously there's some overlap, but you're most productive in Tim's role in you're complimenting the skillset of the person writing the code.
A common refrain in basketball is that people forget it’s a team sport. Doesn’t matter how good you are individually if your team sucks (see Michael Jordan in 1988 or Lebron most of his career). Similarly programming is a team sport. Individual stats are not the same as team success.
https://www.espn.com/nba/statistics/rpm
For 2022/23 Green ranks 38. His defensive impact is very high but it is offset by his negative offensive impact.
It’s easy to fall victim to the McNamara fallacy (I’ve certainly been guilty of it), before you start understanding the innumerable intricacies in the domain. And basketball is the only domain I probably know better than 99% of HNers lol.
That being said, GP’s general point about Draymond is very true. Yes he’s one of the best defensive players of all time and one of the smartest as well. I think the main point is his incredible self awareness (yes get the jokes off). On defense it’s more subtle, such as not over committing and leaving his man etc but on offense is where it’s obvious. As his own shooting has fallen off a cliff, more and more when he’s dribbling unguarded he frantically looks around for Steph or klay to flow into a dribble hand off to pry them free for a shot.
He’s talked extensively about the criticism he’s faced for lack of shot attempts, with his rational being why would he ever shoot if he can instead try to get Steph a shot. He’s also mentioned if Klay hasn’t touched the ball in a few possessions, he makes sure to get Klay the ball with at least a decent look; otherwise the next time Klay gets the ball he’s shooting it regardless of how bad the shot is. He also frequently pushes the break[1] to catch the defense off guard and before they can set up.
He is still a negative offensively, but why I appreciate draymond so much is for the above reasons and the myriad other subtleties he does to maximize his benefit to the team and diminish the detrimental elements of his.
And lastly, standard plus minus is still a hell of a lot better than box score garbage, I don’t mean to crap on it.
[0]: https://squared2020.com/2017/09/18/deep-dive-on-regularized-...
[1]: http://stats.inpredictable.com/nba/onoff.php?season=2022&tea...
(Steph actually ranked higher than Dray last year in pace (seconds per possession) on/off which is why separating Draymond himself is so difficult. Their relationship is certainly symbiotic, but Draymond is the one that optimizes for best interplay of their skills)
In this case, Tim from the blog post is a football defender or a linebacker if you're an American. Measuring them based on the amount of goals they scored or a touchdowns they caught is stupid. Instead they're stopping costly errors and providing the foundation that allows others to go on and score. You're probably not going to win very much if you field 11 strikers or 11 wide receivers.
Without quantifying it or comparing to an alternative, this is just feel good commentary. If you deliver any value, that does not consequently make you a good business decision. You have to pit your value against your cost and the companies best alternative option.
Also, if a company measures my value in widgets, I have found my career does quite well assuming widgets is the right way to measure my value. Assuming you know better than everyone in management is prideful and not good teamwork.
The argument here is which metric, or are metrics good for anything? [1]
[1] Except ditch digging and children. It is well known that 9 people will dig a ditch in 1/9 the time one person will, and 9 women will make a baby in 1 month instead of 9.
People like the one described in the article prepare a pipeline of good engineers, who also have experience in the domain and in the organization.
So if one cares about fast delivery, get a good number of sr engineers who work on their own thing, share little and are not encumbered by each other. If a company needs to deliver urgently this works, but is an (expensive, short term) option.
The value of writing good code is self explanatory. You probably use some of his code today.
But he was also great in a firefight: customer is dead in the water and it might be our fault. He’d show up cold and “jam his fingers in the holes in the dam”: quickly figure out what was wrong and then rapidly write and install the most hideous spaghetti code that cot the customer up and running. Code that could not be checked in, or be refactored. Eye-bleeding stuff. Someone would have to take the time to engineer a proper fix, but the immediate crisis was averted.
I was actually much more impressed by the latter skill — among other reasons it’s simply rare. Also he was just a nice guy and everybody loved him.
(Won’t name him since I described some of his code as hideous)
Not exactly something to encourage, but it sounds like he has experience in competitive competitions, where generating code to a problem on the fly is necessary. It's not something you can't learn yourself, but rote memorization of common problems and solutions (to the point where you can mechanically type down some algorithm from memory) is the bane of my existence
In my experience production fires are rarely put out by rote algorithmic knowledge, the skill is more having a detailed knowledge of the inner workings of every layer of the system so that you can come to the right conclusion based on the very limited information available in the average production monitoring system.
.
>the skill is more having a detailed knowledge of the inner workings of every layer of the system so that you can come to the right conclusion
Yup, and that's transferable skills from competition coding. You're not juggling algorithms in your head per se, but you juggle whatever tribal knowledge needed as options to cycle through. That combined with the above mindset can lead to such skills.
Yes it is. Putting out fires, quickly, is very important.
The problem comes later when the breathing sapce arrives to regularise the fix and replace the band-aid with good quality code.
At this point no fire is burning, the problems are not immediately visible, and it takes very good management, right up the stack, to fix that sort of problrm.
> Not exactly something to encourage
Yes. Exactly right. Because the band-aid with all its ugliness becomes the permanent fix because there is no revenue box to place the work in takes to fix it into
Yeah, that's what I was getting at. Especially in my industry, we don't get too many chances to convince the product managers to "go back and actually fit the code". From a business sense, it's a great skill, but business realities equate it to the ability to plug up a dam with a cork.
"This will fix the problem for now, BUT it will make _everything_ harder in the long run unless we spend time to do it properly".
Then when they complain about stuff taking longer than it should I can just refer to the ticket/email/meeting memo and remind them that I did say so.
We're set up a weekly meeting to alleviate the issue and it's working OK. The hardest is finding out which "type" is the right one, when it's not an emergency but there's a tight schedule/unclear specifications... At least we make a common decision
This is, of course, rectifiable in Jira by allowing a ticket to have multiple people assigned to it.
...unless they aren't using Jira and some tool that doesn't allow this.
Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week.
Teams that gamed the system and understood the impossible task they were assigned always gave the highest points total to a ticket they could or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers.
In an environment like that playing by the rules is a suckers game.
When I eventually quit, every sr engineer at the company; 7 total, followed me within 4 months.
So in the short term, the company benefited, yeah? They got more work out of the same people than they would have if they didn't apply the pressure.
Reminds me of an old boss I had who would flat-out say that to get a project done we would "hire someone and burn them out" - he planned to only get six months of useful work out of someone, and if they were stupid enough to stick around for high stress and low pay, that's just a benefit to the company.
(I didn't last very long there either)
But it sure is a shame we're past the days where you actually want to retain and nurture tribal knowledge. imagine if other engineering disciplines simply hopped companies every 2 years, or if they cut half their civil engineers for a better earnings call (thankfully, he government doesn't have "shareholders". just taxpayers to disappoint).
The management decided to base bonuses on "number of open tickets assigned to a person measured on day X". Smaller being better.
(Un)surprisingly I got a bunch of tickets assigned to me on day X-1 and they were reassigned on day X+1. I didn't mind, since my bonuses were determined by customer satisfaction =)
But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns.
I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds like the devs who you think gamed the system, were mostly behaving the way scrum is meant to incentivize. Happy, stress-free development that delivers consistently improving software.
(Minimum point totals per week leading to inflated point values is terrible management, though.)
The issue with scrum or any process that involves estimating is that every software project will inevitably have some risky element or difficult to estimate task that is essential to the execution of the project. Scrum will incentivize teams to avoid the essential work and guide them towards work that is easier to estimate.
Certainly having a good product owner can mitigate this because she can do the work of identifying and breaking down the intractable to something more actionable.
But in that case you’re depending on the people on the team to make good choices. Smart people can do that regardless of the development process they’re using. It’s unclear what value scrum brings to teams at all. It doesn’t make bad teams work any better and it restricts how smart teams can operate.
One thing that scrum does give is it provides management metrics they can use to measure performance.
You are exactly right here. At this company though, that risk on a personal level could mean a pip. So the happy teams inflated the story points massively to ensure that any or no risk was accounted for and they survived to code another day.
Say you’re developing software for the next Super Bowl broadcast - it’s useful to know whether you’ll deliver what you said you would. If it’s looking like you can’t, you can start to make educated decisions about what work to cut and get a better idea of what you actually will deliver.
In your Super Bowl example, you'd either get a team that would focus on doing the scrum activities but never deliver anything useful regardless of how many points it would take, or you'd get a burnt out team that's on the verge of flaming out. In either case "Story points" provide you with no predictive capacity even though predicting would provide value.
But it's an important tenet of scrum that velocity is only meaningful in a single team[0], the root management failure in OP's case is comparing different teams.
[0] and teams cheat themselves too. I recall one advice early in my career that a velocity increase with no underlying process change was likely to mean.. that the team started to overestimate complexity, and one should understand what went wrong.
When a team shifts projects, and changes members, there are too many variables and not enough data points, so points become useless.
Since most teams change both of those thing fairly frequently, in the close to 20 years I’ve been doing this, points are generally not helpful.
You can't estimate non-trivial software, and if you are doing trivial predictable work, you should be automating it, not endlessly estimating it.
I didn't say I would "deliver" anything. It's done when it's done. You can't predict the outcome of a software project. Many of them fail and micromanagement makes them more likely to fail.
so if you automate trivial predictable work (for example by making a CRUD app generator), you're moving to non-trivial software territory with costs unknown (as you said, you can't estimate), potentially very high
On the teams that played fair, it was a mix of sr. and jr. and the sr. measuring that story at a 3 meant the jr. was working the weekend. Over and over again.
Note: On the happy team, we had almost no supervision, not even a scrum master. We just looked out for each other. That 3 point story often suddenly became an 8 as the end of the week approached and no one blinked. That team incidentally was the only one that consistently got good reviews from management.
What does "played fair" mean? Did this organsiation have a fixed definition of the value of a story point?
EDIT: The reason I ask is because when story points are used "correctly" their value is defined entirely relative to the previous output of the team which produced the estimate. Like, their purpose is to allow dev teams to do relative estimation (which is pretty easy to do), but also enable someone to produce absolute estimates based on the team's track record of delivery. Team says a story is a 5 pointer? Query previously delivered stories which the team also said were 5 points and if there's enough data you'll be able to forecast with reasonable certainty how long it will take them to deliver this new story. Used this way there's no "fair" value of a story point - it doesn't matter if one team uses point values in the range 0 - 1 while another uses point values in the range 1,000 - 1,000,000.
The whole thing breaks if you start comparing point values across teams, or say that 1 point is 1 day's work or whatever.
I left engineering for an engineering job in finance. No scrums, no POs, just trader driven development and I haven’t looked back once. Glorious.
In my experience this is usually handled by pushing back on the requirement or kicking the can down the road.
Maybe as-written but not really ever as-practiced.
I’ve worked at places where it was more important for management to know what to expect than to achieve raw productivity towards a goal.
The people who were estimating in good faith may have assumed that management was acting in good faith. Whereas a lot of projects are created aspirationally or have artificially short deadlines to “motivate” people. The stress they incurred may have just been for the emotional satisfaction of a manager and not have provided any more value than that.
I read this as the teams that attempted to measure in good faith did a poor job at estimating. If management tells you that you are required to deliver 10 points per week, then 10 points should take you 40 hours with rare exception. Whatever other idea you had in your head of what 10 points "should" mean is simply incorrect.
If its 10 points a week then you estimate based on the assumption that 2 pts is a days worth of work.
That, coincidentaly, is what ours roughly shakes out to be.
Sounds like the stressed teams were lacking in common sense.
Even in an environment where story points essentially mean nothing it already ends up with some people just wanting to put high numbers on everything.
The only usage of points is to improve the predictability of the output of a team. It cannot be used to measure performance in an absolute way.
If performance metrics are built on points, it just ruins the meaning of points. There is no reason to be honest anymore.
Unfortunately in my current experience my manager is not at all like Tim.
Senior engineers in my knowledge and experience are all delivering on something relatively high impact while contributing massively to the team by occasional/often "pairing".
I've seen rare examples who don't "pair" but just deliver by themselves.
I've never seen an example where they don't deliver on anything (planning, design, architectures included) but only "pair" as their job every day.
But I don't sit over someone's shoulder at all times. I only try to help when I'm needed, otherwise I'm knee deep in my own deliverables.
I asked to swap teams. Two levels up both said "no way you can't be replaced. "
I have a reputation and didn't know.
Also these activities might not always result in a lot or any artifacts. E.g. being in a meeting, making sense of messy stream of requirements and using institutional knowledge to help set the right priorities on a project or prevent team from spending months on a dead end idea might not leave any paper trail at all.
Also: the business established a metric it wanted ICs to meet, the guy in the story refused to participate in it at all. At the very least, he's demonstrating resistance to following the expectations of leadership. He might be a good team player at the smallest scope, but great engineers can do that and simultaneously play along with management/biz interests.
(I'll also agree with the article that measuring "story points" or whatever is probably a bad metric, like most measures of software productivity.)
That said I believe the author that Tim was a huge net positive.
>Enabling technology teams to operate at their full potential
Sounds like he is a very particular type of developer focused precisely on enabling teams in this manner.
-----
also, I can just post the obvious here but: he may be doing work but not tracking it. I've never been perfect at creating stories for every task I get, especially retroactive ones that pop up in the middle of the week.
The real reason Tim showed up as having zero productivity was because he always let his pair put their name on the ticket, and so get the credit for it. This is really a story about how things go wrong when a ticket tracker designed for solo work is used by a team which pairs.