Comment by Stratoscope
2 years ago
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." :-)
Unfortunately I am in the middle of central New York, but I sent you an email anyways, just to say thanks for what you have done and continue to do!
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.
So without someone like you they would literally not repair some units? I guess they chuck and replace them?
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 ;)
Have you found a way to keep up with the "question answering"-part while working remotely?
Did the culture around questions change compared with working from a shared office?
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.
2 replies →
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.
Just a quick note to thank everyone for your thoughtful and insightful comments here.
As it is a holiday weekend, I may not be able to get back to every reply right away.
I am grateful that zdw's submission and my comment led to such an interesting discussion! Thank you all.
I hope that feedback didn't discourage you from continuing with your approach to software development and teamwork.
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.
That’s good feedback I think.
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.
1. https://noidea.dog/glue
2 replies →
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).
1 reply →
It's easy to say that until it affects your paycheck.
PSA... check out this guy's LinkedIn profile. It's a great read.
Thank you! You gave me an excuse to look at my own LinkedIn profile, which I've ignored for a few years.
I have a distinct memory from not that long ago when I was unemployed and asking people for advice on what to put on LinkedIn and on my resume.
One consistent piece of advice was "Don't list anything more than five years ago. People will think you're old!"
I thought, "Screw that, everyone already knows I'm old."
So I decided to just tell my story, all the way back to the beginning in the days of punch cards and Teletypes.
I am grateful that you appreciated that.
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.
Much can be done with self advocacy
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
yep, you have to be loud about your work, especially if it is not trackable via other direct metrics like ticket count
So the performance metrics are ticket count and how loud you shout about your work?
> Some 20 years ago... I called "house calls": visiting other developers' offices...
Ah, the good ol early 2000s, where devs had "offices" or "cubicles" to themselves.
Now I have a whole house with two offices, just for me!
Lucky you.
That’s only a problem if you chose to work somewhere mandating RTO. I have a great personal office and kitchen where I work.
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.
> a few months later
> Which was exactly what I thought they had hired me for!
It's good to regularly update your manager with what you're doing and accomplishing, as they may not realize it at all.
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 always viewed my manager(s) as people with the authority to get what I needed to do my job, not as people who needed to constantly monitor my work.
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.
[dead]