Some 20 years ago, I worked at a moderately large software company that sold a desktop application for Mac and Windows. The team had mostly Mac experience and they were just getting their feet wet with Windows. So naturally the Windows version had some problems.
At the time, I was known as a "Windows expert", so they hired me to help improve that version and help the team get more familiar with Windows programming.
I would often spend the first part of the day on what I called "house calls": visiting other developers' offices to either pair program or troubleshoot bugs or just talk about Windows API best practices and the like. (Yes, we all had private offices!)
After a while, one of my colleagues asked a question that stuck in my mind: "How can you afford to be so generous with your time?"
Sure enough, a few months later I got a review with a mediocre rating and a comment: "Your productivity hasn't been quite we hoped, especially considering that the rest of the team has gotten more productive lately."
Which was exactly what I thought they had hired me for!
I know it's too late now, but you are the type of developer that makes our profession an actual craft. Sharing knowledge is the biggest benefit to provide other developers, and too few that decide to go that route are rewarded for it. If it weren't for developers like you, we wouldn't be anywhere close to where we currently are in the software world. I try to give back knowledge as much as possible, because it's not just about the one business you work for, it's also about building up somebody. Know that you're appreciated, even if you aren't getting direct thanks for it!
Wow, thank you. I am grateful that my comment attracted so much thoughtful discussion. But your comment is the one that really touched my heart.
I was reading it to a close friend just now, and I have to confess that I choked up a couple of times reading it.
So again, thank you, my friend.
p.s. You don't happen to be anywhere near the SF Bay Area? If you are (or even if you're not), please drop me a note at the email address in my HN profile.
Anyone else who is in the mid-Peninsula area, feel free to do the same. It would be nice to meet up with people who have an interest in this topic.
I also want to echo this. For me, it’s examples like yours that I live by. It seems like the right thing to do, naturally. Teaching people and sharing knowledge is the often the most rewarding part of my career at a personal level but it is hard to reconcile when it often comes at the cost of my own progression/productivity. I’m spending most of my time helping everyone else be more productive. How’d you end up working through that?
I had a similar experience in the Legal field of all things. I was only a few years in, so could still relate to and be approachable by newbies. I kept my door open (we had our own offices too!) and folks would wander in with questions all day that I would answer.
The result was that my annual review was meh. They recognized and appreciated my work helping the department as a whole, but my individual metrics were lacking.
As I had a family to feed, I just started keeping my door closed and cranking out my own work. My reviews then imporoved. I realized that the large law firm just didn't have a system in place to reward the work I was previously doing, so I adjusted to what they wanted. "There is no spoon." :-)
I did an internship during uni as an electronics technician repairing handheld, vehicle mount rugged terminals, and base stations (rf network controllers before 802.11 arrived).
Each repair job had the same priority but some were much simpler than others - one month I thought I’d take the base station jobs to learn and because no one else was repairing them. They took longer to fix but obviously were more crucial to operations.
At the end of the month PHB held a team meeting where pie charts of utilisation were shown and I had performed terribly against the rest of the (senior and experienced) team. That was the moment I learned that the senior staff were picking off quick and easy jobs for a reason, and that office politics was a thing.
PHB couldn’t understand my reasoning of selecting those jobs and the outcome was his dislike of my performance… glad I learned about poor bosses that early in my career.
I have been in this position where my boss (the owner!) actually was willing to throw equipment away, but thought he could charge the client both for the new equipment, and for reinstalling. Unfortunately in the small business world, I fear this happens WAY more than even I could imagine, having dealt with it.
I had a similar experience to yours. Back when I was the equivalent to what is now staff engineer, my team got a new boss. On paper, I didn't look amazing, but I was constantly helping people.
My new boss admitted at our first review that he had written up a performance plan, but threw it out not long before. What happened was we just transitioned to an open office, and he got to see the line of people who would come to me for help, and how I wouldn't turn anyone away.
I was a little salty about losing my cubicle, but that experience definitely made me appreciate being in an open office.
Of course, I haven't worked in an office of any kind for years and will never take a job that isnt WFH again, so take that last bit with a grain of salt ;)
Switching to remote work also brought about a significant change in the types of teams I work with. In particular, I avoid larger companies, so there's fewer structured relationships between juniors and seniors.
That said, the challenge is getting over the hump of being proactive. I'm not sure if it was working in an office or the agency model of hourly billing plus time sheets, but I find people are far more likely to spin their tires and waste time until I finally convince them that they can ask me questions any time.
Perhaps there's something about working remotely that people feel the need to be more independent workers, I'm not sure. I'll initiate pair programming sessions and ad hoc design discussions to get the ball rolling, and encourage them to do the same. That tends to do the trick, though as I mentioned at the start, my day to day the past 6 years has had much less mentoring responsibilities and opportunities.
It’s important to find/figure out what a company values and optimise for that. Once a reputation has been established, it’s then possible to go about changing things, but not before.
I’ve seen too many stories of people optimising for the “team”, but losing their job or being looked over for promotion due to negative perception from those higher up.
The opposite is also true, sometimes unfortunately. Once a good reputation has been established (whatever is currently valued in the company), any amount of misbehaviour will be tolerated for a long time.
It shouldn’t be this way, but that’s been my experience.
> It’s important to find/figure out what a company values and optimise for that.
One important ingredient for this is to know many companies will actively lie about their values. Typical case is, everyone tells you they value quality and feedback, while in reality everything is rushed and actual suggestions are at best thrown away in the "later" bin.
> Once a reputation has been established, it’s then possible to go about changing things, but not before.
I've noticed 2 patterns in my various gigs in the past: The virtuous cycle where I'm trusted to build something with significant autonomy from the start, I end up being happy, motivated, productive; and the vicious cycle when I'm just a new untrusted cog in their machine, my motivation & productivity plummet.
As far as I can tell I have no control over the initial condition, and the only way I could break the cycle was to start fresh in a new assignment. Some would suggest I suck it up and work my way up, but to be honest I no longer have the energy to pay my dues over and over again.
> As far as I can tell I have no control over the initial condition
There is something: as part of the hiring process, arrange with your boss to get a warm introduction to the team. Make sure that your boss describes the challenges that led to your hiring, your qualifications (and that they're excited to have you on the team!) and present the vision of the positive future impact that you are likely to have.
I've benefited from these kind of intros when I was a consultant. The senior consultant would hand off the engagement to (junior) me by making me look like a star. Also, meeting people in person as soon as possible after you're hired boosts trust.
> I've noticed 2 patterns in my various gigs in the past: The virtuous cycle where I'm trusted to build something with significant autonomy from the start, I end up being happy, motivated, productive; and the vicious cycle when I'm just a new untrusted cog in their machine, my motivation & productivity plummet.
Yeah, I feel your pain on the viscous cycle. For what it’s worth, I have managed to “hang in there” in such situations and the situation turned around. Normally it requires some change in the upper management or getting into a different team/role though (as you said, a “new assignment”).
> Some would suggest I suck it up and work my way up, but to be honest I no longer have the energy to pay my dues over and over again.
I hear this too! It’s a massive pain to have to go through the “we don’t trust you” phase at a new company. Hopefully as we become more senior, this is less of a thing, but for me there’s always been a period of pain when changing jobs.
What happened after the mediocre performance review? Did leave for greener pastures asap? Did you start to optimize for their performance metrics, and stop being generous with your time? Or could you manage to convince somebody high enough above you in the org-chart that they actually hired you for what you thought they did?
Thanks for asking. It all worked out OK. I had a good relationship with my manager, and he actually seemed a bit embarrassed that he had to put those remarks in the review.
I also had a very good relationship with both the VP of engineering and the senior VP who oversaw the entire product and who I'd worked with before on other projects.
I did leave eventually, but it was for unrelated reasons.
Thank you for getting back, that was quite a cliffhanger ;)
I think the reaction to your story is so strong, because many can relate to having a good work situation which eventually turns sour through something like this. It is also good to hear that handling it can be done gracefully. Like many things, it is a two-way street.
What an odd practice. Not sure who conducted the review, but managers especially should be familiar with the concept of coaching, and recognize that you were doing a great deal of it. I am a technical manager myself and spend a lot of time on coaching team members too.
20 years ago when I started there wasn’t anything I experienced that could be called coaching, mentoring, or leveling up. Sure, I could get some time from a more experienced developer to get another set of eyes on a particularly hard problem if I wasn’t able to come up with a solution but for the most part I was just expected to work with minimal explanation or direction. Very little in the way of code reviews as well. I certainly hope this has changed and to whatever extent I’ve been able to I’ve always tried to make myself available to others because sink or swim really sucks.
Around that same time, my first job was at GE medical systems. The team I was part of was responsible for developing systems for digital X-ray machines. We were developing a new mobile x-ray product and it needed some new capabilities. As a fresher out of college I worked on some of the most critical systems capabilities and features and I got brilliant support from my seniors in software engineering and domain experts (radiology + image processing researchers). They literally taught me 3 different things (coding to professional standards, image processing, systems engineering) at the same time and we were super productive as a team. That set the bar for my expectations on how a team should function for a long time.
Luckily 2 years later I went a startup and similar great experience of team work and supporting each other continued. I worked at 2 more startups which grew a lot and were super successful and the culture continued.
Only in recent times, (post 2019) I have noticed that people are obsessed with performance rating systems and gaming them. I notice junior engineers are not as curious to learn or challenge-seeking as engineers a decade. And I notice recently promoted senior engineers are not as talented either. I used to think this had to correlate with dominant programming language – c/c++/go vs ruby/java etc. but I don't know if that fully explains it.
> Only in recent times, (post 2019) I have noticed that people are obsessed with performance rating systems and gaming them. I notice junior engineers are not as curious to learn or challenge-seeking as engineers a decade. And I notice recently promoted senior engineers are not as talented either. I used to think this had to correlate with dominant programming language – c/c++/go vs ruby/java etc. but I don't know if that fully explains it.
The problem is financials on both employee and employer side.
If you actually want to have a chance at a decent lifestyle without being born into existing wealth, there aren't that many options in the first place, and of these IT is the only sector that doesn't take care much about formal qualifications/education - although you're almost guaranteed to make money if you have a CS degree, you still have a very high chance of doing so if all you have is a coding bootcamp and willingness to learn.
However, unless you land in a well funded startup that has money to burn and not much oversight / managers have actual freedom, the organizations capable of paying that kind of money tend to be very large, very bureaucratic, and pay rises are closely tied to some sort of "performance metric" - hence if you want to rise in level and pay, you gotta game the system because HR won't just give you a pay rise based on your manager's good word, they want something as evidence, even if only to insulate themselves against claims of discrimination or nepotism.
And to make it worse, even if you're in the first case of a well funded startup, if it succeeds and grows eventually "professionalism" will creep in sooner or later - either because the company hires enough experienced people (particularly in HR and finance) that bring it with them, because the company gets pressured to do so by investors/boards/unemployment insurance/legal requirements, or because inevitably complaints of discrimination crop up.
>I used to think this had to correlate with dominant programming language – c/c++/go vs ruby/java etc. but I don't know if that fully explains it.
There most definitely is a correlation here. Language shapes Thought and the more complex/expressive a language is the more does that Programmer have opportunities to explore new paradigms/ideas that expand his mind. Your knowledge footprint increases and you do get better than somebody else who learns a "simpler" language and/or just stays at the surface level without any exploration (i.e. i will just use this API and not learn about anything else).
Unfortunately, it hasn't changed much in small business. I try to do the same with my time, but often junior developers want to tackle the newest things, rather than the old that needs maintenance. The ones that listen to you often jump ship for bigger and better things, and I don't take credit for it, but I like to think I helped them along at least a little in their pursuit of more knowledge.
I am the same way with my coworkers. I spend a lot of time helping juniors with their code and doing code review. My boss talked to me and told me to stop helping out so much and focus on my own tickets.
There’s an article that was going around again about ‘glue work’ ([1]) that has a story where an engineer gets caught up doing all this kind of mentoring, coordination and other work like that and then is passed over for promotions because they don’t have technical achievements (though they claim to have become instrumental in enabling everyone else’s technical achievements).
The article never gets to quite the right conclusion - it’s actually massive management failure - what I was thinking the whole way through was “why hasn’t somebody sat them down and told them to do their actual job??”
Mentoring and code review are both super important, but if the organisation wants you to focus on getting tickets done then you basically just have to, unless you can convince them to actually add the additional work to your actual role description or get enough seniority to add it yourself.
But it’s good to have feedback on what kind of work you’re actually going to be measured on in performance reviews, promotions etc.
If you're a senior engineer, mentoring junior engineers IS your actual job, in addition to the coding work. It's arguably the more important part of your job description because junior engineers write most of the code, so you get far more done via mentoring than you do typing on a keyboard
I think this is an important perspective - in the end you need to do what the company asks of you and not what you think is right for the company if the two are in conflict.
The approach the company I work for has taken, is that leads and managers are primarily coders.
I think this makes sense especially for smaller companies, but it does put a extra emphasis on hiring well. Basically, I'm expected to code and helping my team is secondary to that. If I want the team to succeed I need to hire people who are self motivated and competent enough that they only require a little guidance here and there.
Turns out that's very difficult to hire consistently for. Finding self motivated and highly skilled developers just isn't all that easy in todays climate of boot campers.
It’s a balance. Sometimes it is worth spending a ton of time leveling up your team (teaching them to fish), and sometimes it’s much more helpful to have you do the work yourself (we ran out of food and you’re our best fisherman).
I get why people say this but let's be real. You optimize for the review cycle. If I'm told not to help as much I'm dropping it down until I'm told to help more. Then I'll correct the minimal amount necessary.
A bit surprising to hear that you weren't swimming in offers to hire you all the time. Any idea why that was? Maybe you're somewhat picky about the job and responsibilities that come with it?
It was an interesting reading to through your LinkedIn profile. Really liked how you summarized the work and tech used for each entry. When I reached the earliest entry "Night operator" which sounded like the start of a spy novel!
I’m impressed by Michael’s LinkedIn profile and extensive experience. If you ever take up blogging, I imagine you’d have a lot of lessons and experience to share.
I suppose this comment will not be liked very much, but let me offer one another perspective on this. In one team in our organization, someone was hired who offered themselves (by their own initiative) as a developer coach with the intent on pairing, reviewing and in general helping other devs. They were very confident, and as we employ team recruiting, the team decided it's worth a shot, as the candidate displayed knowledge of relevant skills and - as already mentioned - was very confident to educate his peers. It was an intra-organization lateral move, so not much risk involved. Everyone was on board with that decision, and the expectations were clear: they would not be expected to produce code and/or design documents and so on, they should just support the other devs. It should be mentioned that the team they wanted to join was a really high performing team - still (or because of this?) they were open to the idea of having a well-trained, experienced pairing partner and so on.
Well after a few weeks it turned out not so positive. They had quite a broad knowledge of things, but not in depth. They didn't think far enough (like for example, giving the tip to "use a FIFO SQS queue" despite not really understanding the fine-print, but still they persisted and it ended up in a prod rollback), they preferred educating about code style, didn't really listen to feedback (not in the sense of ignoring it, they didn't even realize that they weren't so senior compared to the rest of the team at all) and in general slowed everyone down without bringing much benefit to the table.
In the end they didn't get fired or something like this. They did another lateral move as the team explained why the team doesn't want to continue this. After their next team change, they talked about that this specific team didn't want to accept their help and that they had received bad feedback since they didn't produce code.
Obviously this is just an anecdotal counterexample, but still this can happen as well.
I was hired at a company to help scale their development because their app was growing fast but they needed a leap forward in architecture and approach or they couldn’t keep up with growth.
I documented everything I did from day 1, from what I was doing as well as why.
When it came review time, everything ended up reflecting really well, for I may have closed less tickets than my peers, my peers where closing more tickets than ever, and there was a direct line from my work with them to that productivity increase.
Once upper management wrapped their heads around this they completely understood why I was effective at helping shift features: the A -> B wasn’t possible without me spending lots of time with others and helping with their projects, and we would have needed more headcount to achieve what we did by having me work with the org the way I was vs trying to juggle feature work with it
It’s all about the metrics at the end of the day, in some ways. If you can demonstrate your impact across the board it’s hard to dismiss
I quit a job way long ago for very similar reasons. I cared about raising the level of the people around me. I wanted the junior folks to get credit and advance in their career. This meant my work was not readily visible.
A director said to me: "I can't remember the last thing you worked on." In that moment I knew it was time to leave. I was gone a few weeks later.
Just last February I was let go from the best gig of my career, under similar circumstances. I knew that I was not hired specifically to help other devs, but it appeared to be appreciated and encouraged. Well, I guess not.
I have made this mistake more the once as I actually like working with people and helping them level up. Something I do now is make sure that if I am being hired as a developer of some sort, the metrics of success outlined clearly in my offer letter also include giving mentorship. It’s measurability usually revolves around peer reviews and how much others value my help. I have been accused of gaming my performance metrics because I would literally be helping people until they are able to tackle the problem independently. Which, I don’t know, sounds like a job well done to me.
Then you have to wonder why they're there in the first place. Managers that do not manage and do not know what the people they are supposed to be managing are up to can be missed.
I think that is why it's important for development managers (team leads, tech leads and whatever else you would like to call them) to be either actively doing hands-on work or having been reasonably good developers in the past. Then they can appreciate this kind of work better.
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!
"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 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.
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".
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'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.
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 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.
> ...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.
> 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.
"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.
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).
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 =)
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.
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.
>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.
Evaluating someone’s performance, especially, software engineers by non-tech people might produce dramatic results.
Let me tell you a story about a friend of mine, codenamed tommy. Tommy was an IT guy with incredible skills in networking. He moved to an energy company, fully-owned and operated by the government. Just a few weeks from his arrival, they had to rebuild the entire network from scratch with new, modern, equipments as well as extending the network to all the buildings of the company’s headquarters. They started to look for external contractors to outsource this project but Tommy was shocked by the price the financial department was willing to pay to get this work done, obviously, some non-tech people made the estimates. Tommy interrupted the operation and told the appropriate department he can do the work and needs only the physical equipments (routers, switches, cables) and two guys who can do the cabling. They agreed, and he took the challenge and delivered the work as expected within just a few weeks within less than a tenth of the initial budget. All that he got was a ”Thank you, you did good work” oral endorsement by his boss.
What a time to be an IT techie when your boss(es) are just old-school, who will never understand your true value.
Having some knowledge about how such contracts usually go there’s approximately zero chance of him getting it.
It’s not just about potential corruption but also about how risk averse large organizations are. The tender would definitely include revenue, employee count, and potentially other thresholds, as well as require that X such projects have successfully been carried out during the past Y years.
Serious question: isn’t this illegal? Technically the $job was paying $Tommy for his expertise in networking. If $Tommy withheld that expertise and instead entered into a conspiracy with $friend to launder his expertise for more profit from the company, it seems like double dipping.
The only way (I think) $Tommy could have done it cleanly would be to quit and instead start the enterprise with $friend before approaching $job.
In a system that doesn’t have any forms of rewards, this should be a logical path to follow. In fact, Tommy has considered this approach as the way to go from now on but only when he got hit hard by his first experience.
Absolutely! But after a while he knew why there was no kind of reward whether in the form of a financial compensation, a promotion or even additional days of vacation. Simply because the law of work does not have a section for exceptional performance/achievement.
"fully-owned and operated by the government" - This is the most important reason. For better or worse, gov't jobs are basically not allowed to meaningfully reward exceptional performance. There's just no mechanism for it.
Not to say things like this don't happen in private industry too - it certainly does. But at least you've got a chance. In most companies there is room to meaningfully bonus or promote or otherwise reward exceptional performance. You may or may not get something, but at least you can ask or push for it, and if they want to do it they can.
1. Do the thing they pay you to do, keep your head down and watch the company light money on fire. Bonus points if after the project is inevitably late, you step in to "help" and save the day.
2. Start a consultancy company and overcharge clients to do this work.
3. Realize that many companies will not reward you for your efforts as you expect and go back to 1
While you are consultant, #3 is different. You start charging more for more bullshit mini projects which could be part of the main project. Especially for IT, it is just a whatever-you-can-stick game. I know companies doing stuff like creating 10 page proposals just for replacing a switch. Managers feel smarter when they get charged a lot for some reason.
The manager is also playing the game. Every manager has a manager, too. The n-level manager just deals with n-1 type of metrics and information.
If you're just looking at numbers, something that costs $$$ is "harder to do" than something that costs $$. Any consultant that costs $$$ provides better work (Why would I have paid $$$ if the work wasn't better? Why would anyone charge $ to give the some quality?)
Drag the work out for years and fuck around while collecting a paycheck commensurate with the work completed. Let the company hire the outside contractor.
Then leave, become an outside contractor and you can be the benefactor.
Save exceptional work for small companies that will reward it or your own startup.
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'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
>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
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.
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.
If you don’t own your company, you are always measured on optics. If the person who employs you does not optically see your value, you don’t stand a chance working there. If employment is the measurement, optics will always be important. For those who disagree, I would argue they are arguing on what would be ideal. Sure, it would be ideal to have a fully meritocratic performance system but if someone else is in charge of your employment or performance evaluation, your success is 100% based on their opinion of you. How do they get that opinion? It’s the optics whether valuable for the company or not.
Just to be clear, I’m not talking about programming skill or value. I’m talking about employment and evaluations which I think most people are commenting on.
And also, it’s not mutually exclusive. I know many people who are very productive and also manage their optics well.
Personally I want the seniors on my team actually delivering on the really hard stuff.
Helping juniors do their job is great and all, but you still need experienced people to work on the hard and complex stuff that juniors can't because they don't have the knowledge/experience/people-skills. No amount of pair programming can replace that.
You don't want to be in a situation where you have really really well implemented low-value features, but the high-impact and high-priority hard stuff was not done because some of your most experienced folks were helping the less-experienxed people write effective unit tests or whatever.
A senior engineer can work through a hard problem assigned to a junior engineer, resulting in a well-implemented hard feature and a less junior engineer. Just because a junior engineer is working on it doesn’t mean by default it’s an easy problem—how are you going to grow your engineers otherwise?
The firms that claim to do that almost invariably do not hire people with 20 years of experience, they hire people with 2 years of experience 10 times over. Sometimes that's fine. Usually it's not.
This seems like nothing more than a desire to gatekeep experience? Being employed as a programmer means you're gaining experience...Even if you work at a single company for 20 years, you're not going to get some mythical competence that you could only get by staying in one area. This line of thinking seems like nonsense.
Whether you have a single year of experience 10 times (or whatever ratio you experience) is orthogonal to whether you work for the same company.
Being employed as a programmer may or may not gain you new experience (which is what matters if you are to be a good generalist). Whether it does depends on whether you are _doing things new to you_ while being employed.
Agreed, I will almost always take someone with 5 years of experience at a couple of good shops rather than 20 years of experience broken up across 10 different ones.
Really? I have a lot of 2 year stints, as well as some clients I worked with for 5+ years that always invariably turned into occasional month here and there.
Often the long-term guys I met are the shit guys who are coasting, still writing code as if it were 2005.
Worse still is when their language knowledge has coalesced around an old language version and they're not using any of the new stuff, as I've seen code bases that are entirely incompatible with new libraries.
Like all new libraries generally depend on DI, but all the code is written in static methods and classes so nothing can be easily injected and you get all sorts of threading issues when you try.
Well there you said it, you work some places for 5+ years, therefore I would strongly consider you. The main reason is that longer stints give you an opportunity to become a master with at least one set of tools. If you interview and are apparently not masterful with your own toolset, then I’ve caught a coaster. I’ve found that it’s much harder to acquire this signal vs. noise thing with exclusively 2 year stint people because they spend half of their life on boarding or unemployed.
Also, I get what you’re saying, but DI was around in 2005 and some good engineers (older than I) were using it back then. It seems lot of good ideas skipped a generation!
You are taking the wrong lesson from the article if you think they are saying every (or even most) senior developers should be doing this. You absolutely don't want every senior developer spending their time mentoring/working with junior developers, but having a couple of those people on the team is a force multiplier and benefits the team as a whole. They may not have realized it when they hired him, but he found a useful niche and once the company identified it they should have changed his role to make it official.
Agreed. Tim was not doing the job of a programmer if he never actually wrote code that delivered value. Tim was a coach. Which is fine if that's what you hired Tim for, but I suspect that if you wanted a coach, you would've hired one. Hard features simply can't be done by juniors even given infinite amounts of time: they just don't have the skills yet, and to gain those skills takes years. Sure, they need a senior to help now and then, but if that makes the senior developers produce nothing, then what's the point for the company?? Just give hard features to people who are senior enough to do them, and if you really want the juniors to learn, let the senior share easier parts of that work (and walk through what he's doing) with the junior.
It's very nice of Tim to help everybody else, but doesn't anybody find it odd that all the other programmers need lots of help in the first place, so much that Tim has zero time to deliver anything himself? Seems that the problem is not with Tim, but with management that thinks it's ok for a professional to need help all the time, and for a volunteer like Tim to be there for them any time regardless of what he's paid for (which in this case, was story points as made clear by the author).
> Helping juniors do their job is great and all, but you still need experienced people to work on the hard and complex stuff that juniors can't because they don't have the knowledge/experience/people-skills. No amount of pair programming can replace that.
Or, it could be said, you need to refactor your codebase so no job is all that "hard and complex".
Should have had one of those seniors build it in the first place, eh, then juniors could be trusted to modify it. Or, what you say, he did? Then why is he "a senior" in the first place, if stuff is "hard and complex" because of how he built it...?
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.
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.
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.
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?
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.
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.
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).
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.
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.
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.
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.
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.
> 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.
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.
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.
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'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".
> "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 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.
"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.
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
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.
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 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...
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 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.
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.
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...
> 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.
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.
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.
> 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....
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...
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
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.
> 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
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.
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.
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 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.
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.
> 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.
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.)
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.
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.
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.
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.
> 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.
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
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".
Wonderful. In rowing there is a practice called “seat racing” where different combinations of people are rotated in and out of the eight positions to determine the combination that is the fastest. Individual strength is an indicator but it’s the team speed that determines who is in the boat for races. The inevitable result is that the fastest combination rarely includes the eight strongest rowers. There is very often one or two “magical” people who don’t look better “on paper” but make almost any boat faster when added to the mix. They have subtle ways of improving the set, rhythm and power of others. Not all coaches take this happily and resist it, with the obvious result of fewer wins.
This is very, very analogous to software teams. It’s the mix and results that matter most.
When I've been asked to coach someone on "technical leadership" I always ask them to be on the lookout for "facilitator" employees, those whose help makes another employee more productive or effective. I am convinced there are "service oriented" personalities where people get more job satisfaction out of helping someone else do a great job than getting all of the credit for doing something amazing. As the author points out they often "score poorly" and yet losing them will create net decrease in team productivity. I always try to give folks the tools to help distinguish between people who aren't productive because they aren't, and people whose productivity is exhibited in the success of others.
It is never good to measure the "one" metric and manage to that, it results in people who game the metric "winning" and fosters the promotion of such behavior. I pointed this out to Google leadership and to quote Lazlo, "This is the system we have, it isn't perfect but we're going with it, either work within it or don't, it is up to you." :-). That meeting told me everything I needed to know about whether senior leadership was trying to have a better engineering environment or not.
To many new managers come into the job (especially if they were engineers individual contributors before) with the idea that if they keep the "best" members, and move out the "bad" members both team morale will be great and so will the teams output. But they miss that their understanding of "best" is not based on managing people, its based on getting their original job done. As a result they favor people who mirror their skills and habits and disfavor those who have different skills and habits. Getting them to see this and having their eyes go wide with realization is always interesting.
Have you ever seen an organization filled with service-oriented employees and no doers? Zero-interest rate policy has lead to having more Senior Director of Jira Board Management and Lists of Tasks type roles and not enough people that can do the work. I'm not opposed to the idea that others can be a catalyst for the productivity of others, but you need the others for anything to get done, otherwise it's necrosis.
> Have you ever seen an organization filled with service-oriented employees and no doers?
Yes, but to be fair it was an IT organization which had settled on a metric of "tickets processed" for their quality metric. As a result people who processed a bunch of tickets but never addressed root causes were seen as "good" vs people who wanted to fix fundamental problems that would reduce the number of tickets. It was, for me, a pretty classic case of picking the wrong metric. And to be fair the "best" IT/Service org is one that looks like it has nothing to do because it is always ahead of the curve of upcoming issues, and upper management has a hard time with that.
I've asked this question a number of times now: What is the unit of work for software development?
If you work on a factory line, you can measure widgets per hour and quality. In construction, you can measure distance or area completed. But in programming, you are not making a repeatable product like the factory line. You can say that developers deliver story points; that is the product, not the work.
I invite you to come up with your own answer before you read mine.
----
----
----
I think the inner cycle of development is learning and trying. You learn about a system, make a theory, try that theory out, try to extend that theory, then you test. That test will let you learn some more - was I right or wrong, was there some side effect. Then you repeat.
I don't think this learning and trying is a good unit of measure for performance, but I do think it's a good basis for an engineering notebook, which may be reviewed with a manager.
Non-junior developers are essentially managing themselves when it comes to getting the work done. So how do you manage a manager, when that manager is not responsible for widgets?
I have been this person and I'm trying to move away from it. It really is a great skill to enjoy lifting others and to be the glue of a team. But there are multiple slippery slopes inherent to that role that make it difficult. You can begin to confound the knowledge of others as your own, and almost certainly your own IC skills will atrophy if not purposefully maintained. I think it also requires the explicit buy in of the team, or at least other seniors who understand the benefits and can help keep balance.
It just takes one jealous colleague or one "efficiency minded" manager type to completely rug pull you. I know it's valuable because I have benefitted from that person many many times, but it takes empathy and a lot of balance.
A very relatable story. Of course, we all feel sorry for those other Tims out there who were not lucky enough to have such a good manager. Partly, because we see the Tim in ourselves.
I think this is what we can do to help: Remember sometimes we are also those co-workers who took help from Tim around us and conveniently forgot to Thank their contribution in success of our project. A simple thank you note in the right meeting, slack channel or in the project delivery mail goes a long way. Measuring the indirect impact of an employee is hard, even if you were the manager at any level. Taking help is not a sign of weakness or acknowledging the contribution of a co-worker doesn't make your effort any smaller.
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.
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.
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)
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.
I've never seen these kind of people (Tim). Almost always, it is someone who knows absolutely nothing, meanders from desk to desk, wasting productive people's time, picking their brains. They are usually never given any work, because someone else has to undo the damage and do the work!
Then then socialize with managers outside of the team, bragging about how much 'value' they're adding and they can talk as if they helped others. They move around a lot, getting promoted each, adding no value other than just talk with no clue on how to do things.
Yep. Even in the unlikely event that he's really that good, he's doing only the fun part of the job and shirking the other 90% where you turn your brilliant code into something that actually does something useful for an end user. A better manager would take action.
When I joined my company, I was introduced to this dev who'd been there since the start.
His English wasn't great. His Javascript wasn't "modern" - he kept using callbacks etc. He often poo-poohed ideas the younger wizz-bang devs had. And so I was warned - basically he's an old curmudgeon, set in his ways, he can't take any criticism but he'll dole it out, a pain to deal with.
I quickly learnt how untrue that all was. OK, his code isn't great. BUT he's 100% committed to delivering customer value. He understands the ins-and-outs like no one else. He thinks through every scenario from the customer's perspective, and absolutely NAILS it every time. The young devs didn't like him because he didn't give a shit about "GraphQL versus REST" or "Hapi.js vs Express vs Koa vs whatever".
Where the other teams would avoid involving him in design conversations, I'd pull him in straight away. And our team reaped the rewards of integration projects that delivered right out of the starting gate, rather than customers kicking them right back with complaints.
Had this same issue, new young devs adding the latest programming tricks and saying yes to every fking thing as if a no will get hurt their “I can do anything” mentality. Others were not pushing back as it may make them look stupid or something, they treat the project like a social event.
A lot of these little things came back to bite hard
I worked with a copywriter who did similar stuff and made the team tick. It was great to watch him effortlessly get everyone doing the right thing for the project and it worked both ways, he'd communicate effectively with the dev why we needed to hack things and with the business about getting us extra time for certain things. It lead to a better project with a manageable amount of technical debt.
He was let go and the project became a lot less successful and enjoyable, once he was gone a large group left soon afterwards...
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.
I was a colleague of these guys at Thoughtworks and my favorite most relatable tidbit was telling client managers “no”.
High performance teams at Thoughtworks really had almost full autonomy over how they worked. At a particular credit card bank in Delaware circa 2006, Jay Fields and I demanded (and got) flat screen monitors, our own conference room to use as a dedicated bullpen and most importantly, unfettered access to the open internet via custom holes in their firewall. Crazy times.
The title is a fairly harmless form of click-bait.
What the author describes is the effect on a solid senior engineer working in a terrible organizational system for a not very skilled or savvy manager.
Such managers (and directors and VPs) are common, even in the top tech companies. They may occur less frequently in those companies, but skilled, savvy managers are much rarer than excellent engineers, so the dysfunction described continues unabated in all companies.
> Instead we would measure stories delivered, or it may have been story points (it turns out it doesn’t matter), because these represented business value. We were using something like Jira, and people would put their name against stories, which made it super easy to generate these productivity metrics.
I have never worked anywhere where middle management measured individual engineers via issue-tracker metrics. That seems almost implausibility dysfunctional. It’s not just measuring a hilariously wrong thing at the wrong level of granularity, it’s also disempowering the line manager from evaluating their own people. Is this a real thing companies do?
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.
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.
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.
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.
It's interesting reading this because this has been my role for a few years. I've also had similar problems with management wanting to pip me and things like that. Luckily, my company does peer review in addition to top down review and that has shown that I provide value even if it's not always coding.
I think the managers who don't understand this type of role are the ones who were largely mediocre engineers, but were able to get to that position regardless. They just don't understand the process of engineering and that's it's not just churning out tickets or doing the bare minimum if you're working on something non-trivial.
> Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team.
This was the money quote.
Teams do big stuff.
Good teams do good big stuff (very good).
Bad teams do bad big stuff (very, very bad).
It seems that the hyper-competitive nature of today's workplace means that engineers consider their own teammates to be "competition," and we never really get a good team. This is especially true, with the mayfly tenures of most engineers, these days.
I'm fairly happy with the fact that I was able to keep a stable team of experienced, high-performing, senior C++ image pipeline engineers together, for decades.
Other managers would bust my chops for being a "Santa Claus" manager, because I refused to burn them out, and often intervened, when other managers were being too hard on them.
It seemed to work. When my team was finally rolled up, in 2017, the engineer with the least tenure had a decade.
This is brilliant. I'm a mid-level engineer with decent C/C++/Rust background. Have yet to find a team like this. I'm inspired by your story to keep searching!
The moral of this article seems to just point out what we all already know, and what has already been discussed on HN countless times: don't measure performance solely by things that should never be measured in a vacuum (like story points, lines of code, etc.).
Not sure why this is the #1 article on HN right now, other than maybe the (what I would consider) click-baity headline. But I wish there was an acceptable way for HN to use more fitting titles for articles (especially since most articles always use a click-baity headline). E.g. would it be at the top if the title was "Don't measure performance by story points"?
I guess some interesting anecdotes have resulted in the post, but the message of the article itself doesn't seem to share anything particularly new or enlightening.
>E.g. would it be at the top if the title was "Don't measure performance by story points"?
TBH it's a non-zero chance here on HN. "Don't measure by story points" is still preaching to the choir to a community like this after all.
>I guess some interesting anecdotes have resulted in the post, but the message of the article itself doesn't seem to share anything particularly new or enlightening.
1. Lucky 10k. Especially if it involves some managers who may in fact be doing this stuff as we speak
2. Generally, I come to the comments because some anecdotes are more interesting than the article.
Agreed, but also: enough people are disagreeing with the moral of the story that I think we can no longer assume anything in the article is preaching to the choir.
I actually don’t think that’s what the author is arguing. They are arguing that certain metrics that are valuable to measure at a team level become less useful or even misleading if you zoom in too far to an individual level. Story points being a good example. Useful when talking about a team, not useful when talking about individuals. That’s a more nuanced point, and one that I definitely don’t think is obvious to everyone.
> I guess some interesting anecdotes have resulted in the post, but the message of the article itself doesn't seem to share anything particularly new or enlightening.
Enough commenters here on HN are disagreeing with the article's conclusion that I think we can infer this is not a point everyone here agrees on, and the article was needed after all...
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.
For Tim MacKinnon's sake I sure hope you got Tim's permission to post this, and that Tim is near retirement age and not needing to interview for any team in the future because unfortunately, searching for "Tim McKinnon programmer" tells me he is the worst programmer in existence. If I were hiring and found that as the first link on Google, and feeling particularly lazy that day, Tim's C.V. would be round filed. HR would reject him before I ever got to see his C.V. Poor Tim.
I know a dozen programmers like this. It's true that it's not easy to get fired if you're a constant benefit to the team's productivity, but it's very hard to get promoted under most organizations' promo guidelines, which usually involve design documents and end-to-end projects.
Don't spend all your "empowerment" energy at one company. Companies WILL undervalue "glue" developers (and also "glue" teams). Eventually being so focused internally can hurt you.
Instead, if you're good at helping others, do it publicly. Speak, blog, participate in open source. Turn your "helping others" energy into one of helping the broader development community. Pay it forward there and it will reap more dividends.
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.
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.)
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.
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.
Whenever I’m forced to do a periodic performance/peer review, I just think about how I’m doing my manager’s job for them.
I’ve already spent the last quarter either complaining about coworkers or praising them, now you write the damn report! And as for the self evaluation, again, you write the damn report… unless you have no clue as to how I’m doing, to which I say, your performance really sucks as a manager.
We all know Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure". Quantitive measure done't work well and especially not for something as complex as software development. They might tell you were to look more closely at best. Qualitative assessments work much better, but those require trust. As soon as going gets tough for a company or department, trust weakens, doubt increases and higher management, especially if they don't understand software dev well, will require quantitive metrics. It's bad, but we'll never get rid of the mess because of organizational dynamics.
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?
The worst programmer I knew never had any productivity problem; if anything he produced too much code, outpacing the others' ability to maintain certain levels of quality.
He ended up promoted; in many organizations, people that hack the code rather than properly design and build sustainable solutions are highly valued.
Yeah, that must have been my collegue. Usually he was in charge of implementing all the new stuff, because he was able to deliver fast. And then I had to refactor, or usually just rewrite and redesign the whole thing, because it was immediatelly unmaintenable. I didn't mind, since at the end of the day, he was really good and doing these prototypes and selling them to management. I was good at making the application last and stable, so it kinda worked out.
By no mean I am the best dev I know, but I consider myself the best one with finding answer that I have met in person. e.g: fixing bugs, reading docs, even for things I have no exp about.
Anw when I was data engineer at a big corp data team, I was the one the 2 seniors there with 20 juniors, like fresh out of the colleges. So the juniors ended up ask me with everything since it was faster than googling them self. I still deliver things in my responsibilities since I can do it quick, also spend like one third of my times to mentoring them. Later, I found out that my manager thought I was slacking off, not working to my full potential.
Yes, the manager never payed attention to how the team worked. All the juniors thought that I was the reason the team was running smoothly and quickly. Ok, fine, I realized sometimes you cannot just work, you need to sell your work, even in your companies.
The nature of data engineer job is to ensure things run ok. So everything too well for a long time, then the higher ups might think it is easy. It might sound like bad thing, but when a bug happened, sometimes I let it be if it is not too serious, to let it rises to the higher ups. Of course being able to solve it quickly is a must.
> 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.
"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.
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.
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.
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.
>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:
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?
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.
<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 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.
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.
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.
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.
I wish I could pair program more. I have so much knowledge to give other members of my team. Domain knowledge, programming knowledge, common pitfalls, etc. You get a code review pass at the time of writing the code, and it means you have more opportunity to change things for the better. Once it's written there's not much appetite for drastically changing working code during code review unless there's a really good reason.
But it's usually contained to someone like a junior calling me up and saying "can you help me?". The answer is always "yes of course!" and I share as much as I possibly can. But it ends there.
I just want to sit down and show them things. Teach them in a way that makes things "click" the way I found they clicked with me. But I don't think management really values this approach. We get siloes of knowledge and then when someone leaves it's all hands on deck to transfer that knowledge.
I'm often brought onto projects as a firefighter because I'm seen as productive. But I think the more important thing for the team would be to have me upskill everyone else below me. But for whatever reason, it's hard to get that point across to management. I can see myself in a few people and that they have potential, they just need encouragement.
In almost all companies, even seeking help is frowned upon. One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'. Some actively don't want to help out others, due to PIP/bonus culture. At Amazon, some team members explicitly give bad advice when asked for help. That's why we have this culture of "lone rockstars", who spend a lot of time to learn without being mentored.
Seeking help isn’t the problem. It is priorities. Usually the best developers are tasked with the more impactful tasks whose deadlines must be met at all costs. As a manager, I would view my task is to shield said developer from distractions so he can save my butt because my job is also on the line.
If someone is intentionally giving bad advice, that sounds like they deserve some anytime feedback. (is that still a thing?) That is definitely not thinking like an owner.
Name-and-shame culture on the internet is toxic and ruins innocent people's lives. When someone conscientiously keeps a person anonymous while describing one or more of their flaws, there's no need to ask them to name the guilty. There's enough unnecessary permanent reputational damage going around on the internet already.
this post is really strange because it actually describes a good environment
- code isn’t changing in code review except for really good reasons
- people who need help are reaching out
- projects that need help get additional help brought in
what else are you looking for? this example is about as pair programming as it gets at most places. they’re called silos when people don’t like them and layers of abstraction otherwise but they’re the same thing: no team will have 100% shared info on all parts and knowledge transfers on exits are a decent step to bridge this
if you want to teach the team more, teach them more. usually the best way to do this is in code review. it’s direct comments on code. write a good review you want more people to see? post it in the chat. set up additional time to share ideas with the team. all of these things you can do as an IC while producing code
sorry but this post comes off as “i’m smarter than everyone.” i’m guessing the reason management hasn’t gotten your message is the message isn’t clear. what exactly do you want to do? and what do you need their help for?
I don't think code reviews are the _best_ way to teach. Because for a start, you're usually working with a complete task. Someone can have a perfectly fine pull request that implements the feature or solves the bug, but it might not be the best way of going about it.
Now, as a reviewer your spidey sense tingles and you get the feeling there's a better way. But now it's significantly more effort to pull that change apart or start from scratch and experiment with a new approach, then write this all up on the pull request with the caveat "but what you've written works, so in the interest of time we can merge this".
Pair programming would get you on the right track from the start. You are able to assist an inexperienced dev and guide them through the process step by step. Imbuing your knowledge, raising questions, suggesting fixes. This is exactly what the blog post describes. The developer was seen as unproductive because their time was spend pair programming rather than directly doing the work themselves.
I don't see how my post comes across as "I'm smarter than everyone". I know things that less experienced developers don't know, and that's a fact I know from talking to them and reviewing their code. But the culture just isn't there to be able to spend significant portions of my day effectively being their teacher (which I would love to do!). Instead it's often "the blind leading the blind" while the more senior members of the team are off delivering important projects and not having the capacity to imbue their knowledge onto the less experienced members of the team.
It's a culture thing and I wouldn't say it's a good environment for nurturing new staff. Spending 2 hours in a Teams call or at someone's desk is uncomfortable for both parties in a company that doesn't encourage this sort of collaboration. And so there's a sense to not "waste someone's time". The person you're helping sees themselves as a burden rather than seeing themselves as a student. And as a teacher, you're conscious of the other work you're supposed to deliver because it's not expected for you to be spending significant parts of your day pair programming.
> But now it's significantly more effort to pull that change apart or start from scratch and experiment with a new approach, then write this all up on the pull request with the caveat "but what you've written works, so in the interest of time we can merge this"
this is your issue. you’re approving prs due to perceived time constraints that you wish you could say no to. are these time constraints real? even for significant prs of 1-2k lines responding to a comment of rewrite another way only takes 1-2 days. code review isn’t about finding the best solution. it’s the best solution given the current trade offs. things to ask yourself are
- are the time constraints real?
- does the team agree on the “right” way?
if there’s time constraints sure i get it. these are external commitments. public deadlines. it’s hard to ask for additional work like this. but in my experience these are rare. usually management is smart enough to avoid external deadlines
does the team agree this is the right way? are you pushing your own narrative? if it’s a team strategy, it’s very easy to tell people to rewrite an entire pr for. if it’s your opinion but you can defend it, make your case, and if it’s strong you can still get someone to write it. is this so bad it’s going to be rewritten soon?
> the more senior members of the team are off delivering important projects and not having the capacity to imbue their knowledge onto the less experienced members of the team
i thought you were saying you are this senior engineer?
i don’t get this. you want to spend more time helping people but think it’s uncomfortable to be on a call with someone for 2 hours getting through a problem. you want to pair program and feel this way about a shared coding session? i’ve spent literally 7 hours on zoom screen shares. if you’re actually helping people they appreciate it
you say the culture isn’t there to support this but then list examples of good places you could create this culture and choose not to
if you truly are this smarter, better engineer that should spend all your time helping your team, why aren’t you doing these things on your own?
I think you're viewing this in a very idealistic way and not a way many companies actually operate.
You can me ask "why don't you do X". And the answer is that the culture does not support it. I have work to do, work I've been given because as senior members of the team we are pushed into bigger and more important projects. The less experienced members of the team just have more time to do things.
For me to spend 7 hours a day sitting in a call with someone would mean 7 hours of not delivering work that my manager and project managers expect to be delivered. No person in the business is going to want to spend 7 hours on a call because the culture does not encourage it. This is why I said it is uncomfortable for both parties. Taking hours of someone's time isn't seen as a good thing, it's seen negatively. Of course the person you're helping appreciates it. But the culture makes them feel guilty for asking.
Should that be the case? No. Is that the case? Yes. Am I working toward that not being the case? Yes.
I don't know why you think I'm not trying to change the culture. I've literally listed all the issues and ways to fix it. It's not an overnight switch.
Pair programming sounds so stressful and unproductive to me. You can't read someone's mind. Any interjections while someone is in the middle of coding can't be more than distracting noise most of the time. And I would constantly feel self conscious that I'm taking too long to write something, googling or asking Copilot stupid questions, etc. Reviewing after the programmer believes it's ready to review makes much more sense to me. Though Copilot can be very helpful as an artificial pair programmer.
The point of pair programming isn't really to be talking to someone while they are coding a known solution. It's to work through and discover a solution together to an unknown. In this sense, you're kind of both in the same headspace together, and can have a conversation without necessarily breaking focus. And I would venture that almost any question that comes up in pair programming would either come up later in code review, or could be hand-waved with "yeah, I plan to fix that with X" and move on.
The important part of pair programming isn't really the programming per se, it's the discussion.
It also requires some amount of conversational art. As for being self conscious about things, you would have poor coworkers who make you think that or some unfounded worry. A good pair programmer can have a discussion without making you feel like an idiot - much the same as a good code review.
I agree with you for a case where you are taking a feature from start to end. The case where you are spending half an hour unblocking someone who is stuck or brainstorming a better solution for something tends to be beneficial though.
Frankly it sounds like you need to make this happen. I don't know your company culture but at places I've worked Staff+ engineers aren't meant to wait around for permission to be catalysts and mentor other engineers.
I'm usually the catalyst for change, but that's usually around tech and process. It's more effort for me to try and change my managers mind on what our development culture should be. The company I work for has a reputation for being a bit of a grinder and I've managed to help reduce that reputation in my team gradually at least.
But at the moment I have work to do and deadlines to meet, so it's a hard sell to suggest stepping back from active development and focusing more on incubating our less experienced devs. Even though it's better in the long term, and my manager would even agree on that, important short term projects just take priority.
Optimizing team efficiency is a team effort. It is a false dichotomy that you either work on “important project with deadline” or do mentoring. There are deeper structural problems that you need to solve first imo.
Apparently I am pretty lucky. My managers are explicitly asking me to help rescue a project AND get the dev who did most of the work upskilled and following some of our patterns from some other successful projects. It is hard to know whether they are actually taking my advice and changes to heart and integrating them into their knowledge base and mindset, or just accepting that they're being asked to make changes by me and doing them.
Mentorship is hard, regardless of management buy in :/
Pairing gets a lot of hate and is very misunderstood. It can be terrible, though, if the org doesn't encourage and teach it. There are also lots of things about pairing that are misunderstood, especially that things take more time.
I was on a team that paired all the time and it's sort of ruined me for anything else. We switched pairs daily and everyone would pair with everyone else (on the team). When a junior joined the team they would very quickly lose their junior status.
Have juniors plan out work first in design doc form and broken up into small deliverables. Helps to catch things early when they start down a rabbit hole.
Yes very similar. It makes me very happy when I'm called over by a junior proactively. Not mainly because I'm able to help them, the real reason is that they sensed something about the problem that needed a second pair of eyes, and they didn't waste time. That's them gaining intuition and experience and I get really happy for them.
I don't actually say it though because I don't know how to express it.
I feel that the article is talking about the same thing as what is described in this talk https://www.youtube.com/watch?v=YyXRYgjQXX0 - "disagreeable givers", which the host of the talk argues are one of the most valueable employees to have in a company while also being the least understood and often let go.
I am a disagreeable giver myself and I have experienced a lot of backlash by the higher ups inside companies for being one, while also being praised a lot by my colleagues that were working alongside me.
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.
I don't buy it and they sound like a very annoying coworker. If he's 100% devoted to pair-programming and makes such a massive difference, promote him to a lead. Programming is the only profession that acts like it's literally impossible to ever measure productivity at all without committing some obvious wrong. Drives me nuts, coming from a blue collar background. It's cargo cult thinking used to justify many negative outcomes.
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.
"measuring developer productivity is that you can quickly identify the bad programmers"
The author has obviously never tried to build anything non-derivative in a team. This metric only identifies the noisiest inexperienced programmers, that go through other peoples work... like a monkey on crack throws its poo. These folks are often successful in business, because anyone that actually grasps real workmanship is already busy. The main problem is meritocracy eventually fails, as someone biased must choose what constitutes "good" work. Thus, a pseudo-Technocrat just follows foolish idealism with extra steps... and becomes a Marketer in time.
The truth is "all software is terrible, but some of it is useful..." depending on the end use-case.
I find it amusing and very telling that the organizations with the most burdensome and unnecessary overhead are always the first to take an interest in developer productivity. A metric which their own structural inefficiencies are in direct opposition to.
The problem with the story is there is a reasonable solution for the bean counters: you log time against tickets you work on or help with. Then maybe prorata the points to the hours.
The issue now is of course you are just incentivising taking overestimated stories. This cat and mouse never ends. Crucially you are punishing/removing the glue people that do the stuff not specified that needs to be done. So now you need every little thing on the board. And a lot of time on arguing about what should be on.
It is worse when the tasks allowed on the board
have to be agreed by a committee that meets on a Wednesday. Not joking that has happened! But that is another story.
Metrics. I used to work on a team with skills in agile development. The process was evaluated at every retro and everything was tweaked. One member of the team however continued to put tasks into states that was not even in our agile board. Meaning. You could not drag a task into that state. You had to set it. Turned out that the idiot CTO used an unknown report to evaluate staff. One metric was putting a task into a specific state no longer used by our team. The idiot CTO had told his favorite pet dev about this metric.
Too bad I quit before the CTO, CEO and most of the board members got fired. Would have enjoyed sitting there and going. Yes, yes, yes.
As a manager in technology I'm starting to really detest stories like this, because they are often bandied around by IC's with a very narrow view or opinion of why it's bad to do new change X or Y "because here is a story", which on the surface may be similar to what happened here but is in fact a good idea. In reality things are always so much more nuanced, or require much more context to judge, than what people naively think.
In this particular case, I can think of a few reasons why the original scenario that this team was in would still be considered "bad". For example, maybe Tim received tasks to do and he didn't do them, now the company is behind on things. Maybe the other people are not as good as their job as they should be, but because of Tim's interference that's being hidden. Maybe the expectation is that the other people are as good as Tim, so why are they not helping each other out as much as Tim is? Should Tim get a promotion, or are the other people performing badly compared to their position and salary? Maybe the tasks that Tim was supposed to do are more important than the ones he's helping others with. Maybe the company didn't budget this much investment (2 people) for a specific thing that needs doing, and as there's just so much engineering time going around, what other tasks are now receiving less time than budgetted?
There's so many ways where this story may fall apart in a real context. Obviously, something has to change (expectations, budgetting, salaries, job levels, etc...) to align reality with the direction that the company wants to go into, and that change is not necessarily (limited to) "keep Tim around and have him help everyone out and everyone will be OK and this is the optimal scenario and management bad".
The implication also being that "evaluating people on story points is bad", but that completely disregards the fact that doing this has surfaced an issue in the department that needs resolving (and before I get pitchforks thrown at me - that issue may very well be that Tim needs a change of job title and a promotion) - but obviously expectations and reality didn't align beforehand, and the story point metric surfaced it and allows for resolving it. In that sense, the story point thing yielded benefits that otherwise wouldn't have been had.
This seems a lot like trying to invent a problem to justify your metrics rather than acknowledging that your metrics don't align with the actual performance of the team.
There's no indication in the article that the team was struggling or under-performing, and there's no reason to promote someone out of a position they're thriving in just because the way they deliver value doesn't neatly align with how you're measuring value, especially if you can plainly see the value.
Here's what I've seen in the past: exactly the scenario you described, the "Tim" is promoted to team lead or architect or something similar, and now their calendar is booked up and they no longer have time to do the thing that brings value (and that they enjoy). No one on the team is happy, everyone is stressed, and in a year or so you'll start bleeding members. Tim either hangs around and is a mediocre whatever position he is, or he leaves to be a whatever position somewhere else where he can start with a new context and without loaded expectations.
I agree that firing people based on delivered story points is probably wrong. I disagree that measuring the amount of story points someone delivers has no benefits. In this case, it surfaced a very interesting dynamic in a team that apparently the company wasn't aware of, and now that it is surfaced, it can align that team better to the goals of the company. I would really wonder, for instance, how Tim was evaluated on performance, if the expectations of him didn't align with the role he was doing.
I think the part in the article where a manager wanted to fire Tim because he delivered 0 story points, and the teamlead (?) refused, is made up for dramatic effect. I can't imagine any manager seeing those type of results and instead of asking the teamlead what's going on there, jumping to the conclusion that Tim should be fired.
At the end of the day, it's all emotional and biased human beings subjectively evaluating/judging other human beings. This guy that worked with Tim believed that he added great value to the team. A manager came to a different conclusion. It's impossible for them to determine who is "correct," let alone us. Of course we can come up with all sorts of potential scenarios but it seems pointless and unfounded without first-hand knowledge of the situation. The skill of being a manager is deeply understanding the specific and individual nature of their team rather than trying to apply a more generalized "playbook."
Edit: By that I mean that I am highly skeptical of metrics used to evaluate people. It's a lazy way to make the job easy and avoid doing the hard work of getting in the trenches, gaining unquantifiable insight into what's going on, and effectively communicating that up the chain.
Of course. My point is that this exact same situation, at a different company, may have surfaced a Tim that actually should be PIPed because he wasn't doing what he was asked to do, or his contributions weren't as valuable from an objective point of view (but of course all his peers love him taking some load off and them being able to get all the credit), or he was forcing a team dynamic that should be "fixed" because Tim is actually a Brent (from Phoenix Project) that had to have his hand in everything and the team couldn't survive without him, yet it may be difficult to discern these situations from the situation described in the article where Tim (sounds like) he was definitely bringing more value to the team than a replacement would.
Yeah it's a few hypotheticals onwards, and there's probably better ways to surface those problems, but companies are messy and no one is without flaw or 100% competent, no engineer and no manager.
(Note that I'm not saying evaluating a person based on delivering story points is optimal, or even useful)
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.
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.
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.
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.
These are the moments employees decide to quit. Managers are clueless and just creating evaluation metrics to impress upper management/ceo/owner. Upper management also is clueless and believe the manager. Eventually the IT company, the consultant, or the employee starts arguing with the company and they are replaced swiftly by the management. This costs a lot to the company but who gives a crap. They deserve it. Before this happens just drop the client or your employer and find a better life.
Ugh of course the worst programmer you know is actually the best one. While I agree with it, there is nothing new in this article and the obviousness of the bait and switch is depressing.
How timely, I hit similar issues, I often end up removing blockers from my team when pairing, which doesn't end up visible in Jira and now HR is bothering me.
"Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team."
- This happened years ago to me, with a manager pulling me aside and asking why my Tickets resolved were so low... They only cared about the number of tickets worked on...
All I had to do was read the title of this article and the first sentence to understand that this is an example of what's wrong with the software development industry. I would rather work with people that act like good people and are human, than to work for the idiots measuring your every breath looking for a reason to fire you.
When I got promoted to a Senior Dev, my job became totally different. All I did the whole day was talking to other teams, pair program, organize big project nobody wanted to do, take part in plannings, but hardly any coding. These responsibilities were actually included in the job description.
The business mindset wants employees to be contestants in a reality tv show. The process of creating things doesn't look like a commercial though. Progress doesn't care how you feel, it's a functional process that produces a clear perspective. Greed always obscures that vision.
> 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
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.
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.
There is something about metrics that messes the thing being measured.
Suppose the bank Tim worked at decided to measure the number of pairing sessions each developer participated in—I suspect this too would destroy the team.
When you measure people doing X, you are really measuring people pretending to do X.
The only 10x coder I knew was the one that managed to deliver stuff (almost) on time but also took the time to explain things to other (junior, me at the time) programmers. Such Tims are sadly rare and I think I should start working towards becoming like one.
i have been looking for such a thing for long time.. always had to do that AND also coding and architecting and generaly moving the whatever project. Except just once for 4 months (from ~15 years).
Well, last 2 years i played that without the coding part (as a CTO!).. but not sure if anyone up-there noticed.
So i slowly start to dispirit and go bitter.. Seems Consumerism (throw-away-buy-new culture) ate the software/knowledge profession too.
i don't know, either noone needs deep, experience-backed, 360' looking knowledge, or it started grow on trees?
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."
DORA seems ok as a big company framework, where different teams of similar sizes can be roughly compared using the scores, and the CIO or CFO can have some satisfaction about being able to avoid spending money on non-producers, without engineers feeling like they're being individually spied upon. Without this accountability, engineering managers may let non-performers coast for a variety of reasons.
For small companies, engineering managers & direngs should be aware enough through working with the team members individually & through PR review who is performing and who isn't, and not need to deploy metrics.
This is not an argument on the merits of story points or metrics but Tim could have just put his name on the stories alongside the folks he helped. Problem solved.
Or maybe Tim didn't care about story points, he knew his worth, and he felt that if the company wanted to fire him on such an arbitrary metric, it wasn't a company worth working for anyways. In the end, he did well because he kept his job and the company dropped an inappropriate metric.
Tim was the worst programmer. I'd be so bold as to say he wasn't a programmer at all. He was a mentor and a leader and should have been promoted rather than sacked to replace whatever taskmaster your team had at the time.
I also have a Tim in my team but he is a net negative.
Most of the time he would try to pair up. He just make noises that implies he is following your work. But you can see that is not the case when he tries to make a comment or a suggestion, he is clueless. Trying explaining things to him is a waste of time.
Rarely he decides to work on a task himself. No matter how trivial the task is, he needs someone to spell out what to do step by step. Even then when he sends a code review, you can find some surprises. He becomes a net negative because he can take a task that should take 2-3 hours top for a regular dev and then spends 1-2 week on it while also wasting more than 2-3 of someone else's time.
It is always fun to see him grab an easy looking task that is way beyond his capabilities and then struggle for weeks and tries to weasel himself out of it.
I never saw someone so immune to learning. He is in the team for over 2 years yet has a productivity of zero. I don't understand why companies keep such people
Or, the past isn't the present. It was very difficult to get a job in the US in 2008 and now it's easy because it's 2023. (slightly harder for some kinds of tech)
In Europe firing people is not always straightforward.
There are so many people doing jackshit which make me go insane.
I guess, good for them and I'm glad I'm not a shareholder.
Management handle the most blatant cases in 6 months.
There are so many people who are not completely clueless at pretending to do something and they go undetected for their entire career.
From previous experiences, in a US startup they would be fired in 2 weeks.
What value to society does making companies carry dead weight provide? It raises the company’s costs, lowers productivity and morale, all to protect someone unfit for a particular role?
The unpredictable layoffs and terminations of US companies are their own issue, but companies pay unemployment insurance to let people go with some safety net. I can’t imagine UI is more expensive than keeping an underperforming employee.
Unfortunately, I have seen many of these types of people pass by management. The worst ones are the ones who do play political games correctly because they’re the ones who either get away with it at the very least or worse, make the talented engineers want to leave. Basically, the latter can completely destroy good teams.
Yup, I’ve seen many people like this in engineering. They “put all their skill points” into Charisma. Then they go on to build long, prosperous careers by bullshitting and charming senior management, until they themselves are promoted to senior management. It is a reliable, proven career progression for the incompetent.
They need to fire his manager first and then assess this guys capabilities. Maybe he is not guided enough. Maybe he is plain stupid. Full responsibility of his manager.
This is also why the most hilarious anti-feature of Jira, supposedly a tool to manage agile teams, is how every ticket has one person assigned to it. If you do sufficient pairing, the person assigned to a ticket is completely useless. Also why performance measurement from the outside of a team is always going to be dubious.
Every team knows their best performers, and their lowest performers. The number of points aren't going to line up with performance most of the time, precisely because time helping others is never going to show up. And if suddenly getting help lowers your review, you are going to ask for less help, not more: Trading accuracy in external performance tracking for lowered team performance sounds really dubious.
Not sure how that solves the pair programming issue. What you’d need is a way to split the points for a single task among 2+ people without the overhead of duplicating the ticket.
It's, what, two clicks to duplicate a ticket, and another to assign one to other person? Sure a "this person paired" button would be easier, but sometimes you just gotta do jira chores.
If only there were some person who's job it was to deal with said busy work because you think it's beneath you. Some sort of manager of the program, who is also technical.
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.
> 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.
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.
> 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.
>People are free to draw inferences about how it would be to pair with this programmer and why they are rarely paired.
you could. but there's not much to work with. could be helpful but "too valuable" to be a mentor compared to a director or pitching sales or doing conferences. Could be overly pompous and makes things worse. Could simply be office culture and pair programming for more than 15 minutes isn't a thing (like all my previous jobs).
All are extreme assumptions that aren't productive to talk about. Personally: I don't know if I'd want to be in those cultures that enforced pair programming X times a week, but I wouldn't mind , say, a day a month where I could shadow a lead or vice versa and get some intimite knowledge, be it in correcting some pitfalls in my coding or seeing how a more experienced mind ticks. But the chance hasn't come up yet.
I'm rarely paired because pair programming just isn't something we do in the company outside of just helping people with their little issues. It's not an encouraged practice. There's nothing deep about it. It sounds like you're trying to insinuate something negative about me.
I assume they are insinuating that you are coming off as arrogant and only interested in teaching. They should definitely just say so, though.
In a good pairing environment everyone is learning from everyone. You didn't explicitly say you were looking to learn for others though you also didn't explicitly say you weren't. As far as I'm concerned, in the best pairing environments everyone is always pairing with everyone else, not just seniors with juniors. There is the idea that seniors can actually learn from juniors too since juniors will question things seniors haven't thought about in a long time and are living with "I do it like this because it's the way I've always done it" syndrome.
>In a good pairing environment everyone is learning from everyone. You didn't explicitly say you were looking to learn for others though you also didn't explicitly say you weren't.
Well that's the thing. The only reason I'm in a senior position at this company is because I never stopped asking questions and I still don't stop asking questions and learning from people more knowledgeable than me. I used to spend hours sitting at one guys desk just asking questions and listening to rants and just gathering knowledge.
I learned that this was the fastest way to progress and get better at the job, but I'm not finding that juniors and other less experienced devs are doing the same thing because they're worried about wasting people's time. And people are less likely to encourage this behaviour because they have high priority work. I got away with it when I joined the company because the rate of change was so much lower and so things generally just took longer.
Yep, I feel this is a general broken thing about our industry. I'm very against the whole, "let juniors do easier stuff," mentality. I'm also very against the "you must make big disruptive changes in order to get ahead," as well. The latter often results in people just looking in the wrong places to try and improve things, often by introducing complexity instead of removing it.
I'm pretty jaded by it all. These days I work for a company whose primary business isn't technology and I'm much happier.
I'm actually quite enjoying how divisive a simple quote can be.
I wonder how often I've made a comment and gotten no engagement. This quote seems to have gotten more engagement than the original comment. And quite emotive engagement.
Makes me wonder what that means. Is it genuine curiosity? Or is the quote saying something that the original commenter couldn't see themselves? It's interesting they suggested if I was insinuating something negative about them.
Importantly, they did not ask me. They told me. That too tells us something about what pairing experience with them would be.
"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.
At the time, I was known as a "Windows expert", so they hired me to help improve that version and help the team get more familiar with Windows programming.
I would often spend the first part of the day on what I called "house calls": visiting other developers' offices to either pair program or troubleshoot bugs or just talk about Windows API best practices and the like. (Yes, we all had private offices!)
After a while, one of my colleagues asked a question that stuck in my mind: "How can you afford to be so generous with your time?"
Sure enough, a few months later I got a review with a mediocre rating and a comment: "Your productivity hasn't been quite we hoped, especially considering that the rest of the team has gotten more productive lately."
Which was exactly what I thought they had hired me for!