The First Time I Was Almost Fired From Apple
41 points by isuffix
41 points by isuffix
“And while I am often quick to point out how much better programmers many of the engineers I worked with at Apple were, I will say that I was the guy that accepted everything that was put on my plate.”
This is great career advice (if you’re with a good employer). Being a “shovel carrier” - being the person who will clean things up and make things better and take on stuff that no-one else wants to take on - will be noticed (by good management).
Do bear in mind, though, that it’s important to determine whether the reason no-one else wants to take on a thing is that it’s unethical. Sometimes that’s the case, and then, it’s best to follow suit.
Being a “shovel carrier” - being the person who will clean things up and make things better and take on stuff that no-one else wants to take on - will be noticed (by good management).
It’s a good way to burn yourself out and become an overburdened code janitor who has to put up with the worst nonsense in the company. Pick your fights, stand your ground and don’t let anyone take advantage of you.
Yeah I had to quit a job once, because of this. Hence my warning - in a good organisation, with good management.
They do exist!
I’d love an example that is presently good in the way that you’re describing.
I can give you some concrete examples, from places I’ve been, at least while I was there.
At one, we had a team of devs who were, basically, all doing this kind of work, most of the time. Cleaning up years of neglect in several large and very important Ruby codebases. We also had one particular dev who was known for his skill in this sort of shovel-carrying work; at one point he went overseas to the US (not that I’d recommend that now!) to help out our sister company.
In a contracting gig with a local tech company, years ago (before they got acquired by private equity, at which point I believe everything went to shit), my main achievement was to rally some troops to fix up their CI system. Everyone hated it and knew it was broken, no-one wanted to touch it with a barge-pole.
At my current employer, appreciation for this sort of work is very well baked in to the culture. Our CEO / founder is well aware of the value of cleaning up & making life better for the team, especially as it’s a small team, so well considered force-multiplier work is of great benefit to the company.
Some observations:
You have to have a line manager who groks the work, and can explain the benefits to the higher-ups as needed (in several cases, that’s been me - either the line manager, or the higher-up).
The higher-ups have to be playing a long-term game. I.e. wanting to build a good, sustainable, culture.
Quantify, quantify, quantify. I’m a fan of metrics (especially in larger orgs) and one reason for that is that they can highlight the benefits of this sort of work.
When it doesn’t work:
Culture of “move fast, break things”. Especially VC-funded companies that despite having hundreds or thousands of employees want to pretend they’re a startup.
Non-technical technical management. Very very hard to explain this sort of work to them.
Low trust (either / both ways).
Yeah I don’t think I’ve ever worked anywhere that rewarded this. Especially larger organizations. Some amount of it is due and proper but what you’re describing isn’t going to be healthy or worthwhile for most programmers.
Reminds me of this post “Being glue” which is a great guide on what not to do if you want to progress in your career, at most organisations anyway.
One thing I’ve found effective is to convince people to show their appreciation for the work you do. I ask how bad something is, and if they’d be happy if I solved it. Then, once I solved it, I’d ask if they could give me a shoutout because I’d appreciate the positive visibility for this work. Managers love being able to point at quotes and seeing how others value each other. The more signal you can spark, the more management will notice. It’s important to get alignment with others on what is important. If no one thinks something is important, maybe it isn’t important. For sure no one will appreciate it.
I’ve started doing this because I fixed some bug in the integration tests that flaked for a couple of years. The release team made a huge announcement expressing their gratitude and tagged my manager. My manager was shocked; she didn’t even know I was working on it. I didn’t tell her because I only spent a couple of hours on it as a side quest. It’s all about getting visibility, and the best form of visibility is gratitude. Written ones are best because you can put them in your performance review and calibrations.
Yes! Visibility is important - a good manager will teach you how to achieve that, even (especially!) for the shovel-carrying work.
I read the comments here before the article, so I was kinda anticipating this quote to be like he took on some incredibly boring and tedious, but important-to-the-business job that had all kinds of ugly code. Say, the internal tax calculator dealing with international legal requirements… all in the form of a huge cross-referencing spreadsheet… and a law changed in one country the middle of reporting season for another so you gotta fix it but you also can’t break the rest of it.
Instead it was about rewriting a color picker from scratch, and getting to design it himself! Golly, that’s the kind of task I’d love to be assigned.
“On a roll, I decided to also knock out a “crayon picker”. At this point, to be clear, the color picker was working and I felt I understood it well enough. I was kind of just having some fun now. (…) And it turned out, to my surprise, Apple shipped all the color pickers. No marketing or design person ever asked for them.”
I’m just amazed that this was the case - must have been satisfying to have your decisions taken seriously and ending up in the final product.
Cool story, thanks. But also illustrative of corporate silliness.
Tangential story, not rising to the level of easter-egg – I’m responsible for the following code comment: https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/abi/apptracecmd/apptrace.c#L210
I did this sometime in the late 90s, well before Solaris was open sourced. I never until today considered that I could have angered the copyright gods.
Be careful out there :P
as a thought exercise after reading this article (which it’s great BTW) I’ll love to hear about what would happen now with current eng. processes inside those big-corp, will someone catch that?
after reading this kind of articles from time to time I tend to ask to myself: were then good old times for real? if you were good enough you will make yourself a career because people on top of you were technical enough to understand that you were good
offtopic: this is the kind of articles I enjoy to read while drinking my morning coffee, I really love to hear this trenches nerdy stories about good old times during golden era of software industry