Honestly, this is one of those traps a team can fall into, where nobody feels empowered to ignore the rest of the business for 3 weeks to put the bell on the cat. The only person without deliverables and due dates is the new hire. And it takes a special kind of new hire to have the expertise to parachute in, recognize that work needs to be done, and then do it with little supervision.
But he's right in general, that you can get some surprising things done by just putting in the time and focus. Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars.
There were two stacks of these, six feet high, waiting for me.
It took me most of a year to work through the pile, finding out why the crash had occurred, by tracking pointers through memory with pencil and colored marker and comparing this with paper listings of the operating system. Then I'd code a fix for that problem, test it (usually around 2 AM when I could take over a mainframe), and nervously put it into production on one mainframe. Slowly, the piles of crash dumps got shorter and the mean time to failure went from hours to weeks.
There were very few meetings, and nobody interfered. They were just happy to see the crash dump pile shrink and the uptime increase.
After a few years of this, by which time the systems would stay up for months, I got a job in R&D at another company and got out of maintenance programming and into theory.
Yeah, it does. I’ve had a good amount of experience doing this. You need to have tact and a kind of humbleness that can be difficult to maintain (tbh, it was for me at least). In my most recent experience with this, many of the bugs were unknown. During my ramp up, I read through nearly all of the code I’d be working on and got a good sense of what needed to be done, but the code changes were the easy part. The issue that required more work IMO was navigating the social waters as a new hire.
I found that you can use being a new hire to your advantage, eg “hey I was reading through this piece of code and I had a question about XYZ.”
Sometimes I’ve felt certain bugs are, for one reason or another, difficult to discuss. One thing I’ve done in cases like this is to refactor a bit of code in a way that makes a subtle bug painfully obvious; then in review, where the reviewers were the original author and reviewer, it’s easier for them to see the bug and say “this looks weird,” to which I respond “ah, yeah, this seems like a bug, I’ll fix this.”
The rough part of this is that you can get so good at being the fixer that this becomes all you (ie. maybe you’re not working on new features, etc) which can suck. The bright side is that you can strengthen the team—-everyone gets a chance to build/rebuild context and mental models, design docs can be updated, and the teams foundation gets stronger as a result. Of course, ymmv.
As a new hire, I find it important to build trust and relationships.
My boss came to me and said "we want to move from AWS to GCP, using kubernetes and not have it be a mess like we have now"
I was new, senior, free from ownership. I chose to stay as a team of 1 so that I wasn't burdened with fires and meetings. It freed me up to put my head down and get the work done.
The grind was learning GCP, kubernetes, terraform, the platform/product, gathering requirements from several teams and mentoring people that would pop into the project as their time allowed.
I won't lie as learning new things was great. The project was partially greenfield as it was a platform migration and not a product rewrite. There were a lot of constraints & debt to deal with.
Maybe the new employee churn is one of the reasons that most startups get so much done... the new people are not burdened by ownership and being the subject matter experts. They are free to do things, good or bad. :)
I've tried to keep that level of intentional naïveté.
This is where a good manager makes a difference. They're also interested in your professional development. They should recognize the valuable work you're doing, have you train new(er) hires and move you into more senior positions, more interesting work, or both, whichever you prefer.
I agree with this statement and your other points. I’ve noticed a more insidious variant of this behavior: the expectation of interruptions. Some groups have such frequent priority shifts and/or a culture of fire fighting or door knocking such that even with a relatively open schedule, one is dissuaded from engaging in longer stretches of work for fear of having it all go to waste when the next meteor strike arrives.
We went from recognising that requirements may change after planning to zero planning and telling developers what's the next priority for the day, day by day.
This lack of planning and product definition is also what drives the lack of documentation, which is another big problem in 2021.
I don't expect going back to waterfall but also not what's going on nowadays. Hopefully we'll bounce back in the middle at some point.
[1] not the project board shape, but the original process it's named after where you set a hard cap on work in progress in each stage to find out where bottlenecks are.
As a person who’s worked in both american and european big companies... I can tell it’s not an american illness only and I have heard the same from asian friends. Best I got was one or two meeting-free days (at least on paper, in reality these would be ignored as well). I just got used to these things.
Ultimately, I've found the important bugs prioritize themselves no matter how sloppy your system is. The rest of the bugs are simply there to (1) provide context, reference (2) serve as fallback if product work tends to lag.
Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed.
This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead.
Put another way - if everything is important or “must fix”, nothing is.
So to the author: that seemed like a waste of time. I would not have done it because I’m not convinced the outcome would have been meaningfully different from my tactic.
This context is really valuable when reasoning about the product or determining what's important to prioritize.
The issue with the "declare bankruptcy and important stuff will come back" is that you don't actually solve the underlying ruthless prioritization issue and very quickly end up in the exact same position.
You also irritate people that spent time writing up product issues for potentially important bugs by auto closing them (so many important things may not come back), but the bigger loss is that going through all of them gives you solid product historical context.
For what it's worth, the best PMs I know go through the backlog and understand what they're killing when they approach a project that's currently fucked. I think it has a positive side effect of giving them a lot of credibility too (as well as helping them ramp up).
It's great for individual contributors who don't care about understanding the product and are probably going to be in another team in 3 months.
In a previous job I did what the author did and it helped building an understanding of the project and with knowing at any time the list of the top X things we had to fix.
This seems like a great idea: technical debt bankruptcy.
In reality, you're throwing away hugely valuable data that people spent real time and effort producing for you.
See also: https://www.jwz.org/doc/cadt.html
And of course that person didn't close their pet project or the features they promised.
It's slightly soothed when it's realized one of your summarily closed bugs could have prevented the next incident or major customer loss.
If I write a bug report, I'm doing the developers a favor by pointing out where they failed in development and validation. Simply closing the report with no action tells me that you don't care about the quality of your code or the way it affects the users; and that I've wasted my time thinking that you did care and writing up the bug.
About 6 months into a job I realized this was what I needed to do and totally cracked. Didn’t know the questions to ask or the way to learn what I needed to so I burnt out quick and quit. My fault for sure, but there was a ton of pressure to identify issues and fix them because senior people were “just too busy”.
Better to have meetings than to have what you’re doing cancelled several weeks in.
Bug reports aren't exactly sui generis, they don't just mysteriously appear.
It likely affects some people more than others depending on the demands placed on you.
Think I'm going request meetings never fall mid morning or mid afternoon.
Knowing about it doesn’t make it interrupt flow any less, unless you just avoid the kind of work that would require flow around it, which still imposes the same kind of productivity impact on intellectual “making” workers. [0]
[0] related: http://www.paulgraham.com/makersschedule.html
Especially since they don’t add any value, but that’s arguably a different problem.
> More trouble than the trick was worth? To you, probably. But not to magicians.
It makes me realize how fundamentally different the values are between some fields. The amount of time magicians put into the craft is mind-boggling.
I see it also with how movies are made -- to think that sometimes they're spending days or months and tens of thousands of dollars, building sets, waiting for the right weather or lighting, braving subzero temperatures, or whatever it might be, just to get a single shot that might be on screen for a few seconds.
Maybe a similar sort of thing with software would be spending time on animations -- the result is a cool flourish, but it lasts 0.15 seconds and it took 3 days to get it just right, and it's impossible to quantify how worthwhile it was beyond a gut feeling. Even still, that's not even in the same ballpark in terms of time or effort.
I can provide an example. I'm writing a programming language, database, and platform to power board games. http://www.adama-lang.org/
Most of my personal investments are marginal to most businesses (or deeply incompatible). If was going to run this as an enterprise, then this would be a death sentence. However, my hope is that when I get this thing moving, then I can ship games quickly with exceptional and redefining reliability.
The only reason I can pursue this as an art is that I'm close to retirement.
I've observed a cognitive dissonance that I can't quite put my finger on. You'll work with (and for) people who have an extreme admiration for Apple products because of the attention to detail and quality. And yet they are perfectly fine churning out terrible technology products in order to make a buck. Often times just little attention to detail can make a huge difference; you don't need to be a zealot about it.
Loosely related: I've found that I've made the most money while working with bad teams on terrible technology products. And I've made the least money working with great teams on great products. I really hate that.
So you make trade-offs.
I realize that more often than not it would likely lead to improvements and a better state of the world. But it can feel overwhelming at times. Whereas working on a shinier smaller thing brings feelings of gratification that much easier and faster.
He does a coin flip trick where he flips a fair coin 10 times in a row and gets heads every time.
https://www.youtube.com/watch?v=XzYLHOX50Bc
The amount of time and effort he puts into this and other illusions is very large.
I think that kind of brute force approach would have been excessively boring to him, and it's much more likely that he switched to a gimmicked coin to get the ten heads in a row, then filmed a few shots of throwing tails for the "explanation".
Larry Wall was quoted in the article, regarding laziness.
Bill Gates has a famous quote, "I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it."
Neither of those people can be accused of laziness, yet they both embrace it. Laziness in the context of productivity is often misunderstood as not doing things, but it is more aptly the stopping of doing in order to observe, think, and let the answer come to you. Work diligently, but think and simplify first. It seems to me that is also what the magicians do.
The difference is that movies are all or nothing productions in an industry set up for a waterfall process with directors who exert creative control. Everything from dealflow to billing to the unions are set up to support the industry's unique requirements. They do the same kind of budget triage as software companies do, but they emphasize the creative aspect far more relative to tech since they're competing over form not function.
The nearest creative equivalent would probably be Jobs-era Apple but I think the best analog would be NASA, whose missions are dictated by scientific and exploratory goals outside of their control. Except instead of an artistic direction, they have to contend with physics that dictates they spend extreme resources on seemingly trivial details like what tape or writing implement works best in zero-g.
Yes and no. There are a lot of "make it fit in the box" requirements when making a movie. The unions mandate a certain make up of the crew, and a certain size, the stage rental costs are a certain amount, there are various laws and corporate budgets to take into account; all that adds up to a certain number of shots you can do in a day, which adds up to a dollar amount, and ALL THOSE THINGS cascade down to enabling only certain creative things. The difference between a brilliant director and a ok one is not the beauty of their art, it's their ability to pull-off something incredible in the middle of all that machinery. In a way, it's WORKING that machinery in your favor.
So while, yes, the industry is set up to support a creative endeavor, that industry runs on a template that makes certain things possible and certain things very difficult. But brilliant producers and directors find ways around it.
A few years ago, I was running a meetup in Austin and a local game studio offered a couple of their people as speakers. Intrigued, I asked about their projects, specializations, etc and learned about fabric animation.
That's when I learned that the Sony studio for DC Universe Online had a "fabric guy" who animated Superman and Batman's capes.
For about half of the mentees, that's roughly true. However, for the other half much of my mentoring ends up being about time management, following through on commitments, and putting in the effort required to get a job done. A surprising number of young people are graduating college without ever having had to work any job. It's particularly difficult for talented coders who breezed through easy CS programs until they land in a work environment where tasks are challenging, expectations are high, and the only way to get things done is to sit down and put in the effort.
One of the best skills anyone can learn is how to sit down, focus, and get work done. In my experience, it's increasing challenging to convince young people that this is an acquired skill that they can practice and develop. There's a growing perception that traits like work ethic, focus, and motivation are fixed attributes that one is born with (or without) rather than abilities that are developed over time. It's frustrating to watch some mentees map out meticulous diet and exercise programs to improve their physical strength, but then turn around and tell me that they're only capable of coding for 2 hours per day as a sort of fixed upper limit. Like everything, the ability to work and focus can be developed over time with practice and dedication. It's worth it.
What do you tell these mentees? What would you tell someone a bit further along in their career who still has the same problems?
Please pm me if you are open to a chat.
titanomachy.hn [at] pm.me
I don't mean "wasting" like relaxing and maybe sorting out a problem in my subconscious. I mean wasting.
I seem to be doing better recently. What I do is focus on doing something. Whatever I will do right now that is remotely productive, that's what I do. It might be refactoring code, or drafting a proposal, or reading a book, or doing push ups, or using the debugger to explore something I need to understand, or playing with some new tech I enjoy learning. Pick up any tiny task and just do it.
It ends up mixing personal and work stuff, which is not great. But at least, at the end of the day, I did something. And slowly I will try to control my focus better to get particular things done.
> what would you tell someone a bit further along in their career who still has the same problems?
If it's a relatively new thing, you might be going through a little burnout. I've been there a few times.
The first time it happened to me, I almost "fell out of it" by accident. My day job was in a bit of a lull at the time and I just decided one day that I'd had it with a lacking feature in Visual Studio and decided to sit down and figure out how to write an add-on shortly after waking up on Saturday. I ended up completing a really basic version that day -- enough that I knew I could do the rest of it, which I continued to work on for about a month until I released it.
I did this all during a handful of free evening hours during the week, but I checked my download counts regularly and was giddy every time they went up. I can't tell you when the burn-out ended -- probably that following Tuesday -- but any time I start to feel that way, again, I look at what I'm working on that I'm really excited about and I often find that there's nothing there. So I look for something new, usually not day-job related, with the goal of it being "far enough outside of my wheelhouse as to require a decent amount of new learning" and "not terribly difficult to do once that learning is over" because if I can't quickly get to a working "something" on a project like this before I close the IDE, I'm unlikely to revisit it. Ideally, that new learning leads to some new things to work on at the day job, too.
[0] Friends are often not the best unless you have a friend who is not afraid to insult you/the "hard truths". I've had a very close friend for most of my adult life that has been willing to say "You're being stupid/evil/what-have-you" when it was necessary.
Also, I'm curious about these statements:
> There's a growing perception that traits like work ethic, focus, and motivation are fixed attributes that one is born with (or without) rather than abilities that are developed over time
Really? Who believes this and why?
> but then turn around and tell me that they're only capable of coding for 2 hours per day as a sort of fixed upper limit
Do they give you a reason? This seems pretty odd.
I don’t think I’m completely helpless about it - factors such as sleep, exercise, environment, schedule fragmentation, etc. do seem to be involved, and I can influence those. But it doesn’t respond to force of will in the moment.
1. Kids with ADHD probably can't develop executive function as fast or as far as other kids. I'm pretty sure I have it, it explains the repeated performance reports of "You're good when you apply yourself and useless when you don't." Unfortunately I struggle to _choose_ to apply myself.
Willpower doesn't seem to come naturally to me, even after 10 years as a professional programmer. Adderall didn't help - I had to take it in the morning, after breakfast. So I was still late for work, because eating breakfast is not something I'm good at, and I couldn't start my day until I had finished breakfast. Then after work the stimulants wore off and I felt like shit and reverted to my normal do-what-i-want executive function. But it made me feel normal without caffeine.
So I quit the Adderall and just cutting caffeinated soda with non-caff every morning, as though I was lowering my dose on a prescription. So far it's working. I still never clean my room, which is status quo for the last 20 years, and work is still pretty easy. The phrase "idiot savant" comes to mind. All I want is for people to stop thinking that I'm doing this on purpose. I don't enjoy constantly feeling like a moron and being behind on simple household chores despite making decent money at a job that is considered (by other people) to be difficult.
And that might even be the case for the kids with detailed exercise programs. I don't exercise at all because it's not my interest. I program, because it is my interest. Kinda like how autistic people can't choose their special interests. I pity the kids whose interest is exercise but are trying to force themselves through a CS program into a career track they can't possibly do.
Dr. Russell Barkely goes into some detail in a 3-hour talk about ADHD here: https://www.youtube.com/watch?v=YSfCdBBqNXY If anyone thinks I don't have ADHD because I sat through a 3-hour talk about psychology, maybe they need to watch it, too.
"There's a growing perception that traits like work ethic, focus, and motivation are fixed attributes that one is born with (or without) rather than abilities that are developed over time."
What if they are, though? What if it's like height, where genetics sets a range and environment picks a point in that range? If I had starved as a child, I would be shorter than I am now. But if I had eaten more, I would not be taller. I'm about the same height as my parents are.
There's a hypothesis that the current age of mass distraction (TV, phones, Internet, etc.) doesn't _cause_ ADHD, but it does _aggravate_ it. I don't know if the studies bear it out, but I really want this to be true. What if it's something that's latent in the human genome, and the fact that we can profit off of exploiting it nowadays just brought it to the surface? In early centuries, if I had nothing to do but my work, maybe I would find it easy to just "accept boredom" and do my work anyway.
2. I'm not sure how many employers would have hired me in college. I get the sense that unskilled labor just isn't worth much anymore, and pushing kids to get more education is kicking the can down the road since, as you pointed out, nobody wants to hire an adult with zero work experience whether they're 18, 22, or even 30.
In the context of this mentoring group, we go through phases where almost everyone suspects they have ADHD for various reasons. This is usually triggered by one of two things: Either someone shares an online "Do you have ADHD quiz?" that is sponsored by Takeda or another ADHD medication manufacturer, or a front-page Reddit infographic misrepresents ADHD as something like "Do you some times forget people's names? Maybe you have ADHD!"
The reality is that ADHD is very challenging for those that have it, but the pop-culture definition of ADHD has become so vague that people who don't have ADHD are increasingly convinced that common life experiences are symptoms of ADHD.
Focusing is hard. Studying is hard. The Grind is hard. It's normal to struggle to focus, but it's even more of a struggle for those with ADHD. However, having to work to focus for extended periods of time, in and of itself, is not an ADHD symptom, it's just life. ADHD is a much more severe impediment.
(Again, not referring to the parent comment): Anyone curious should avoid self-diagnosis and seek a trusted professional. Ideally not a family doctor who simply writes prescriptions on request, but someone who can recommend self-guided therapy programs and combination treatment. Adderall isn't all it's made out to be, especially after the initial motivating effects wear off and you're left with the realities of long-term stimulant use, which are nowhere near as exciting as the first few doses.
> What if they are, though? What if it's like height, where genetics sets a range and environment picks a point in that range? If I had starved as a child, I would be shorter than I am now. But if I had eaten more, I would not be taller. I'm about the same height as my parents are.
Genetics and upbringing may set a baseline for focus and motivation, but those traits are demonstrably not set in stone. Contrary to your example, diet does have a significant influence on height, but it's not the sole determinant.
Height isn't a good example, though. Consider something like running capacity. Some people are naturally more athletic than others, but barring severe disorders, everyone can develop more running capacity through training. Someone who gives up and never tries to increase their capacity may not believe this, but it's true. An average person can't simply work their way up to competing with Olympic sprinters blessed with perfect genetics, but they can significantly increase their running capacity from baseline by putting in the work.
Likewise, attention is a learned skill. Some have more baseline attention span than others, but it can be increased through training and practice. ADHD modulates this, but it doesn't prevent practice from helping. If anything, people with ADHD need to invest more effort into training their attention spans than those without.
> Willpower doesn't seem to come naturally to me, even after 10 years as a professional programmer. Adderall didn't help
Adderall and other stimulants don't provide willpower, contrary to popular belief. Only people without tolerance will experience a temporary motivation boost from stimulants. This effect diminishes as tolerance sets in, which is one of several reasons why drugs like Adderall aren't successful for treating disorders like depression.
Willpower is another learned skill. Expecting it to come naturally won't work forever. You have to learn to embrace the grind, do the work, and power through the urges to give up and do something easier if you want to get anywhere.
> I don't exercise at all because it's not my interest.
The reality is that the things we need to do aren't always going to line up with the things we like to do. You're lucky that you have a natural interest in programming, but you can't expect every necessary activity to have a natural interest behind it. Some amount of physical activity is essentially required for a healthy existence. You may not be interested in it, but that doesn't exempt you from requiring it and it certainly doesn't mean you won't benefit from it.
Some times the things we have to do in life aren't immediately enjoyable. It's on us to find ways to make them more enjoyable (e.g. find a sport you like, or take up walking), and some times we just have to do the unenjoyable thing for the sake of progress.
Somewhat jokingly: maybe you should start doing it on purpose, and call it "prioritizing what matters." If you can afford to hire someone to clean, do that.
But seriously, this sentence really resonated with me. When I was in my teens and early 20s, a lot of things I couldn't change were being labeled as intentional laziness or sometimes drug abuse (I was in reality coding all night because highschool sucked, and never even touched so much as alcohol until my late 20s).
Once I made it somewhat usable, I document it.
After they've seen that, you organically start getting invited to all kinds of more interesting projects and discussions.
I got a bit shocked because I realised this behaviour repeated this past year when I changed jobs. I became a domain expert in an obscure part of the codebase and have been documenting it and sharing the knowledge for a while now.
And inasmuch as you've also improved the testing situation, you've also created a system that allows you to iterate faster, which you are intimately familiar with, allowing you to poke at the system in a way that provides you feedback on your hypotheses. Meaning you can learn about the rest of the system on your own schedule instead of being hand-fed bits of tribal knowledge (which often turns out to no longer be entirely correct anyway).
The problem I've identified is that you're then the go-to person for the task you did in the beginning.
Example: You need to figure out how to deploy X. This is poorly documented and nobody knows how to do it.
Action: You read the code, understand what needs to be done, deploy it. Then, you document it. Finally, you create fairly basic but working automation for future deployment.
Result: Every time there's a need for redeploy, even when the code/procedure hasn't changed, you're the person the team immediately asks to do it. After all, you've automated it, shouldn't take too long, right?
I stopped and refused any work that wasn't directly linked to bringing money in. Within a couple of years my salary doubled.
Generally I have coworkers who embrace the grind - One group happily show up to do some mind numbingly manual and error prone process, even going beyond apologizing into protecting it. That's one form of job security, but it leeches talent from the company. The other group abhors it and will try to do literally anything else to avoid going through it, including making all new things that turn out to be almost as bad (and never quite managing to get rid of the original).
Going through the grind a couple times and making sure that nobody else has to go through it ever again is acknowledging the grind, and then doing something about it.
For me the litmus test is documentation.
Make a active effort to at least explain in plain English was the grind is and what it’s is purpose, then having a stab at documenting the steps.
It’s never a one time thing. Most likely you need to do it a few time manually. You won’t get all the steps right, and automating it will likely be a tall order; otherwise it would be done already.
But like you said I encounter groups of engineers that transform the grind into a cottage industry. They don’t publish their knowledge, they are the expert on it and one of the few group that can execute on those story. It’s depressing.
And you demasked me: by making it better and more documented I want to kill the grind. Or at least offload it to another group. ( BA, users, OPS running grind.sh )
I've found that, as a manager, forcing the grind is also a useful tactic to get a new team member involved. Assign a challenging task that addresses a shared pain point and that requires some measure of tedium and lots of effort.
Not only will the completed work result in a new team member being accepted and respected (as you've experienced), the new team member will also develop a sense of value and ownership in the project. The faster new team members get through that period where they feel like an outsider to where they feel like they are contributing value, the better.
I'm learning Rachmaninoff's Prelude in G minor, probably the hardest piece for me to date. I'm not timing the process but this must have been going on for six months by now. Practice occurs only when I feel like it, as I walk past the keyboard. Sometimes less than 5 minutes per day. Rarely more than 15 minutes.
But it's getting there! If you added it all up, it would be a tremendous amount of work. Doing it to a schedule, or even just filling out a timesheet, would make it too grindy for me to bother with.
So I think When it comes to learning, it's really motivation that is paramount. Not getting bored is a superpower. It's the ability to 'embrace grind' by discovering what's interesting about it.
For me, it's been more obvious with piano as it's my main skill-based hobby and, although I see similar with work, ultimately I need a job to get paid so even if I'm procrastinating over a boring task, at some point that kicks in to make me get on with it.
With piano, I'm only doing it for fun and there are so many pieces out there to learn, so if I realise I don't love a piece then I've now taken to stopping with it after a certain amount of time. At first I would get frustrated for starting but not finishing something, but the reality is that when I find the right piece, those moments you describe when walking past the keyboard and wanting to play happen frequently. With the wrong piece, they happen rarely if ever.
Good luck with the Gm prelude! It's one of my favourites which I have yet to attempt to play but hope to one day...
I personally think everyone should learn at least one song on the piano using this method. It's such a great introduction to how the brain learns. I was amazed the first time I noticed I could actually get better at a song not by practicing longer or harder, but by taking a break and returning only once I felt the urge again (or even better, after a full night's sleep). It's a strange feeling to suddenly glide through a section that you previously found difficult without any additional practice in between.
What are some skills like this that are high-leverage--skills that help with lots of other skills?
If I had to guess, the magic trick was simply investing in tackling all the bugs one after another for a year until they're all closed out. Maybe you needed to triage them all to convince people to invest in doing this?
The factor he did not mention is that there are unnamed people who see certain bugs and when they see those bugs, they judge the quality of the software to be poor.
Thus, for human reasons you must fix certain bugs first because it makes certain people feel that the software quality is not poor.
OR because certain bugs prevent the system actually doing what it is meant to do .... thus the bugs that result in the system failing to serve its purpose must be done first.
The difference between "nobody has gone through this entire list" and "somebody has gone through this entire list" is huge.
But with the bugs organized he could filter the repeated reports and let people work. As a bonus, he could direct people into solving the largest troublemakers first too, so things get quieter faster.
An meanwhile things keep getting thrown on the pile.
If priority isn't clear, you spend hours on a bug, realize it's minor, realize the fix is difficult...and extrapolate that to the remainder of them. Morale sucks.
If someone can stomach sorting through them, then at least you know you're working on the most important bug at any given time.
The problem with tedious grind work is, if it's a communal responsibility, then everyone will just sit around waiting for someone else to take care of it.
I had about a 50% hit rate on the natural force. You just fan through the cards and time it so they pick the one you want. Wouldn't work for the tea trick, but works fine if you have a fallback.
I don't think the trick that's the show pony of this blog post has been revealed to us.
edit: sorry, I hadn't refreshed and seen the other 2 replies before I replied myself.
Do you consider that trick to be sufficiently explained?
It's "one weird trick" to get bugs stuck in limbo for weeks suddenly making fast progress towards a fix, and all it takes is a willingness to do something so tedious and mindless that no other engineer volunteers to do it.
I find that most bugs don’t fall into that class, and for the most part, just sitting and picturing the paths back from the bug is enough to work out what’s going on. If you’re less familiar with the code you’ll want it in front of you to trace your way back. In general you can narrow the search space pretty quickly.
My own personal experience with difficult bugs is that there is no substitute for taking the time to understand the problem domain, the systems involved, and the code itself. Getting to that point takes significant investment though, and I tend to trust engineers who are willing to do that much more than engineers who don't.
At that scale, reading through the commit messages is often enough to narrow it down to a few suspects.
I think I've infuriated many colleagues with this attitude, and I'm sure there's at least half of the people here who would similarly be angry working with someone like that.
Honestly, I'm not very good at writing software, I just tend to be similar to the author -- I grind more than I out-think most of my problems, and it results in a deliverable that solves it, usually, which ends up being enough to move on with.
The message of this story is obviously beyond just our IT related professions.
I really wonder if people do understand what needs to be done but won't. Or that they really don't see a way out of a mess.
Are people really wilfully blind to 'obvious' solutions that are boring, labor intensive and terrible to implement? Don't they see the even worse alternative?
This is in the end probably not about smarts or insight.
This is about something more fundamental: values.
I worked on a team that interfaced directly with the semi-technical "Customer Account Managers" who did the technical setup for customers on our system. The system itself was pretty old, written by people who no longer worked at the company. There are often a number of things that are wrong with the system or don't scale, and every week there is a new issue that would bring down the system.
Without the right manager/PM, other teams would constantly blame my team for fucking up. But every time we tried to work on things that would improve system behavior, a new feature would take priority, or some other thing would blow up requiring the entire teams focus to fix it.
So even though we wanted to fix things, we were in this state where we couldn't put out fires long enough to fix the fundamental problems with the system.
But I think this is also a good example about values. Part of this is also how you 'sell' your story towards other teams, to get buy-in so we all get out of the fire-fighting. I bet you and your team tried, probably multiple times.
However, if that doesn't work, you'll have to cut your losses. Stay for the money or leave for the values. What does an environment do for you long-term?
I really wonder if there is some kind of way to negotiate a way out of this mess.
I guess it will either devolve into total-vertical-transnational integration (imagine being a citizen of Apple), or we'll have to create a new country "for smart people that wanna do stuff", and that entails a whole lotta hard work and problems.
Individual companies may or may not reward the grind over the course of a few years. Companies that don't tend to bleed employees.
These things do pay off over the course of a career, though. The Grind builds skills, builds reputation, and builds an ability to get work done when it matters. The company may not recognize the value of this, but your peers will. Your peers will form your future network as everyone diffuses into different companies.
It's a mistake when someone scales back their own effort and learning simply because they don't expect an immediate monetary reward. We're all building careers and networks over the course of decades. Don't let a lack of pay increases at a single company alter hamper the trajectory of your entire career.
And if you find yourself stuck at a company that isn't rewarding these things, move on. Some other company will gladly reward you for the accumulated experience. It only goes to waste if you stay put at companies that don't reciprocate.
Are there any companies that don't bleed employees? Amazon bleeds employees. Google bleeds employees. Every company I have ever worked for bleeds employees.
The only organizations I know where people regularly have 10 year stints are government agencies. Everywhere else 2-3 years.
It's unfortunate, but the main way to actually see your compensation and respect increase.
I said no. I've been shipping (as opposed to "writing") software for over thirty years, and, if there's one thing I've learned, is that "shipping" software is about 60% - 80% "boring" stuff. I can avoid it, if I'm only interested in "having fun," but if I want to "ship" my work, I need to power through the grind. I also don't believe it's stuff I'm comfortable entrusting to others. When I'm at the car wash, I inevitably see someone driving a car -often not the fanciest ones- through the wash, because they don't trust the attendants. I guess I'm that guy.
I really enjoy knowing that my work is out there, in the wild, and not just in a pitch demo. I consider it a craft, and I love to finish projects. That means that I need to take the time to break out the 2000-grit sandpaper.
That makes it a lot less of a "grind," to me.
But that's just me. YMMV.
I remember the very first time I ever completed (through by work at the time) a psychological profile. (I know such things are mostly discredited, but bear with me). I think it was based around Belbin's team profiles.
I came out as a creative, innovative, 'starter' of things - which actually matches me pretty well: I'm excited by solutions and new ideas, but I often don't complete personal (and sometimes professional!) projects 100% - I've lost interest and moved onto the next shiny thing by then. (Professionally, I'm best with a complimentary team around me.)
A colleague who I got on well with but also often found frustrating, came out as a 'completer finisher'. Which again aligned well with my observation of her and her own testimony of where she drew her gratification from, and also explained why I sometimes found her frustrating: because we were total opposites in this regard.
---
Anyway... maybe the situation you describe on your team is explained somewhat by this? You both want to work on aspects of a project that you find gratifying - but you derive gratification from different aspects?
I enjoy research and design. Thinking about architectures is fun.
I enjoy implementation. Writing code is fun. I enjoy doing in-place documentation; especially as I am usually the poor schmuck that has to go back and refactor or fix.
I really like solving problems; whether bugs, or vexing UX/mental model issues. I'm an extremely proficient troubleshooter. My first job was as an RF technician, so I have been solving problems my entire adult life.
I enjoy creating a software infrastructure, for others to build upon; as opposed to "an app." I've written software that lasts decades, though with a vastly different face. That's kind of a cool feeling. Watching someone take my basic undercarriage, and add a hot rod motor and chassis, is wild.
I enjoy creating documentation. I'm pretty prolix. I was trained as an artist, so I can do fairly decent illustrations, as well as prose.
I enjoy creating localizable software. I've been dealing with different cultures my entire life, and love to explore our differences.
I enjoy creating accessible software. I deal -almost daily- with folks that have various types of challenges, and they help me to keep a focus on what's important.
I enjoy pitching the project. Having a product that is in very good shape at pitch time, makes this much easier.
I enjoy releasing a refined, polished project.
Ah, this is so good. I think you could swap “trick” for “talent” and this would read just as true.
In a bigger team, a big second reason why these kinds of very uncomfortable tasks aren't done is that they also often don't produce immediate business value. You then have double resistance: the PO wants features from you and grinding is boring.
The people who first get to a position where they can spend the time and then do spend the time (instead of doing the even more fun tasks), are worth their weight in gold.
I wonder, what is the motivation for working with these kinds of systems career-wise?
I wouldn't want to do it forever but for a junior to try it out at least once is an important life lesson.
Your statement is indicative of a junior who is unwilling to learn about the system and to do grunt work, which directly translates to due diligence and bug avoidance once it's feature implementation time.
Do not underestimate the value in working in legacy code for learning how to do things, how to do them better, and how sometimes not following the hip technology fad or the more academic approach is the right thing to do.
I desperately wish there was more of an emphasis on the simplicity of quality work in America. That doesn't mean spend years and years making something no one wants. That means making a product that is simple, effective, and elegant. Unfortunately, simplicity is actually harder to figure out than complexity. Adding is easier than subtracting.
I think of software as art. And sometimes it takes an excruciating amount of time and effort to pay attention to the details, stomp out the bugs, and create that beautiful work of art. There are plenty of companies that do value quality, focus, and attention to detail. But far too often, it's about making a quick buck rather than thinking long term about making software that will last years on end.
Are you sure about this? AFAIK the use of words in a language isn't distributed evenly, but according to a Pareto distribution. Thus, you can speak _okay_ knowing only ~500 words, I believe. It won't sound perfect but you'll speak and understand pretty decently.
I once wrote a python script which read words from a .txt file full of french words with their english counterparts and then displayed the french word, waiting for you to type your guess. It gave instant feedback which I thought important for learning anything. The file contained the 500 most used french words according to large book surveys.
This was in my last year of school and it saved me during tests where I had to write coherent sentences in french.
Edit: Here it is! Zipf's law is what it's called.(https://en.wikipedia.org/wiki/Zipf%27s_law) and here's an interesting video about it: https://www.youtube.com/watch?v=fCn8zs912OE
I'd like to think this applies to a lot of professionals work, putting crazy amounts of effort in for a simple outcome, that just works.
except the outcome is not as exciting as watching loads of cockroaches
There's a fine line though. You want to put in the effort into a task where it makes sense, like in the article.
Personally, I see a lot of effort put into tasks where the person is comfortable with the effort, because they know they can do the task manually, the old way, and "don't have time for anything else".
Mind you, all those people will be gone from the industry after winter comes, so I only have to deal with this until then.
The same actually goes for tech too, but here the answer is often that the 100% product isn't on the market yet, and by the time it is finished the need for it no longer exists.
When I started working in Spain as an engineer I solved problems like that in the article, very hard, requiring people with very high technical skills. Companies creating big problems because short term mentality made the bluff to accumulate until emergency came.
There was an important distinction with the protestant-puritan mentality of the US. After doing all the hard work and saving the company I was paid in peanuts and more work, filling all my time and making my life miserable.
Emergencies bring enormous social pressure over you, you overwork and it is painful. They called you because "short term" mentality but solving the problem always takes more time that what they demand you take. It must be done for yesterday.
The big bucks were given to the people that took the bad decisions in the first place at the top. I went to Asia and the culture was even worse, albeit this time I was benefiting from that.
Then I discovered places in the world where hard work was rewarded. It is a very small part of the world. Most of the world does not work the way the Silicon Valley does, and even there socialism is coming to those places too.
So I won't recommend that you work harder unless you are rewarded from it, that is your culture rewards you for that or you have your own business and work gives you an advantage.
I would recommend the opposite, simplify your life so you need to work less, make other people(delegate) or specially machines do the hard work for you.
Do not embrace toxic relationships. Let companies in eternal emergency mode burn and die, and work for(or create) those that do the right thing.
This is about fixing issues where spending two hours doing boring work (manually bisecting) can be better than spending two hours thinking about the problem without necessarily reaching a solution.
Nothing about underpaid overwork, just to do The Boring Thing.
I'm also trying hard, and failing, to understand why you're talking about socialism.
I think of success as having infinite patience for doing a few boring things repeatedly.
Some other parts are having a higher mission to embrace the grind;Some call this purpose.
Something else I have observed by studying other engineers is the theme of not depending on your technical skills alone. One needs to market/show their work to the right audience, own equity in businesses/business.
"As a technical person in your career, you must not rely on your technical brilliance or rest on your laurels. You must acquire some financial education. There is a tendency for technical people to think that they are the best; That they will always be on top; That will be always be creative; That their inventions won’t be usurped quickly by newer inventions. However, history says otherwise. Life was quite unpleasant to Tesla; He died alone and poor depending on handouts from former associates. A tragic end for one the most creative minds of the early twentieth century."
https://leveragethoughts.substack.com/p/dont-hinge-your-care...
Grind is management/company/etc. that says you have to work weekends and late all the time because there's more money to be made that way.
Grind is doing that epic job of organizing and triaging the bugs, then your company doesn't give you a bonus and you're expected to do it all the time.
Doing the right thing is what he did.
I just hope his company did the right thing back.
Well, for some people it is indeed impossible to keep on working on boring tasks regulary without going crazy or dying inside.
I feel like this. And I was proven right on quite some times - to not do an endless work of stupidity - and instead find a clever way around to automate and save on it.
Famous example would be the young Gauss, whose teacher gave them the task of adding all the numbers from 1 to 100, expecting them to be busy for a while. And Gauss just did (n+1)*n/2=5050 and was done.
The problem is just, that very often there is no magic bullet like this and the work remains just dull work (like in the article) - and then you can just loose by searching for the magic solution, while avoiding the actual work.
Organisational it makes sense, to have enough people capable of reliable doing dull work - and smart (but lazy) people who come up with clever tricks to save the dull workers at least some grinding.
Particularly if it's a one-off problem, you're often far better just doing something. Anything. Whatever comes to mind first. Just take some sort of step.
You may find that the problem isn't as hairy as you thought, and in fact just by continuing to do stuff, you solve it pretty quickly. When that's not the case, doing stuff often leads you to the kind of understanding that allows you to put in place a good plan, where just starting with planning forces you to make a bunch of incorrect assumptions that you then have to fix when actually implementing the plan you worked so hard on.
There is a trap in over thinking the automation. Sometimes the partially manual solution takes an hour full while automation takes 8. But I'm failing to think of a time in my career where a grind was repetitive and fully manual but not improved by some trick of automation. Notepad++, regex, and your language of choice builds a very powerful set of automation for virtual problems. For the enhanced suite, toss in a library to get data to and from excel and access and another to navigate and scrape HTML pages.
Even magicians who know many tricks will still enjoy the show and appreciate the effort.
Prestige is a great movie about this very topic.
The scenario the author described sounds just like the beginning stages from the Phoenix Project (overwhelming amount of tickets, what's the priority, what even are all of these tickets, printing them out to make the work visible).
The concept is Work in Process (WIP). You first need to see it and understand how it moves, or doesn't move throughout the DevOps system.
It seems like there might be a quick, easy read that could truly help OP.
[0] https://www.goodreads.com/book/show/17255186-the-phoenix-pro...
I joined a team with 2000 compiler warnings, then set up CI. The "compiled, but with warnings" orange box stayed orange, even as I started killing warnings a few at a time. Then I put a "grep warn | wc" in the CI and another colleague got into the game and drove the warning count to zero a few days later.
I immediately checked in -Werr and we never had a compiler warning problem again.
Grind, but have a plan to stop grinding.
This made me think of something I read about John Resig. He had created somewhere around 75 open source projects before jQuery. Reps, reps, reps indeed.
Actually, what he did doesn't sound boring to me at all! I love cleaning and organizing, and it's one of my favorite things to do as a programmer. But it's the type of work that we tend to feel like we don't have permission to do.
Every time, people up the chain have been aware but haven't acted, when usually the solution is (unavoidably) making the time and space available for a capable person to do it, and having then be incentivised/rewarded enough to proceed.
Off topic: I was hoping based on the title for an unusually technical skateboarding article.
We called it the P3 graveyard.
And there's always that lingering feeling that there are few nuggets hidden in there that would resolve the majority of them.
One time I had to fix a bug that was estimated at 40 hours and consisted of getting Python 2 type coercion in Python 3 (IMO a silly idea).
The users of this program were 5. Instead what I did: I taught them about strings and ints and how to cast (it was some template language they used). I added an answer with some examples to the FAQ.
It took me an hour. The previous programmer on this project never considered manual solutions.
This is fine for a magic trick, but I think the work example may be more difficult to realise if there is accountability. It'd be magic if you can deliver an extraordinary value per time unit spent.
I also think there is challenge and beauty in completing something which you consider tedious. There is opportunity for exercising self-restraint and speed of delivery.
So they did exactly the opposite of embracing the grind and just simulated it.
Here I am, looking at a Salesforce integration to Dynamo.
Several attempts at elegance thwarted by the trashyness of the AWS libraries. The Salesforce data-model a pile of hundreds of ad-hoc fields.
I wrote the most Java1.4 code I ever wrote, copy-pasted the hundreds of fields into a spreadsheet and am slogging through the list picking what to keep and what to ignore.
It will get done by pure force of labor, and the customer will be disappointed by “what took you so long”
Sigh
I've written at length about my Dad's adventures as an entrepreneur, but I remember that one statement made over card group[0] about my Dad's company and my Dad that really stuck with me.
The backstory is that Dad bought into a business he was working for. After several years of success, the majority shareholder decided to retire and sold the business, taking a deal that was highly favorable to him and violating contractual agreements in place with the other shareholders[1]. The end result was my Dad was out of a job at a company he worked hard to build and he did the legal things right to avoid getting here in the first place. The parts of that whole process that weren't blood-boiling infuriating were probably devastating, and I know he lost many night's sleep.
The old company was being purchased by its direct competitor, which was a much bigger outfit, already. Now it would have the manufacturing and (some of) the staff of the old business since OtherCorp[2] decided to keep the old place running. My Dad did get a payout; he probably could have taken that, done all of the investing he did over the years, and ended up retiring in the same position he's in now, but he didn't.
It wasn't that "all of this happened and so he buckled down and worked harder". He always worked hard. The Poker game comment was made shortly after my Dad had decided to open up a competing business, talking about his success at the previous one. And he was about to embark on taking on that competitor and his previous business as a completely new outfit running on a shiny bank loan.
The table was talking about my Dad setting up the new business and a neighbor friend's Dad folded and said: "Hah! They're FUCKED[3]! They didn't buy anything. They don't know that (old company) is Russ (my Dad)! Ford/GM/Chrysler don't want to work with (old company), they want to work with Russ". Then (mind you, probably a few beers in), he went on about story after story of my Dad's various rabbits he's pulled out of hats. The stories were insane--I've got comments written in the past about my Dad concluding a 24-hour workday (as part of a series over a few weeks, I think) with a drive down to a plant in another state to ensure parts arrived when promised, only to be given sympathy by the plant manager -- my Dad wasn't in his usual suit, he had on what he wore doing manual labor. The plant manager took a shot at "the jerk/prick/asshole" who's forcing him to drive all night, to which my Dad said something along the lines of "I sure am", I'm sure, but I doubt he took offense. At crunch times, my Dad was more than "the guy working back in the shop with everyone else", he was the guy doing the worst/most painful job. Assuming skill level wasn't a factor, if a job involved risk, it was his. Now, I'm not saying he was a saint. My Dad did not manage the people, and my high-school friends (who all got jobs in the back in the summer due to near limitless amounts of overtime) used to tell me some hilarious stories about him blowing his top screaming at them for this or that thing[4].
As I grew up and learned more of the story, I learned of the struggles the new company had getting these large automotive companies to be willing to work with such a small shop. At the end of the day, it was my Dad's willingness to take whatever job was given to them, do it better than anyone else and further prove that "that (old company) was my Dad, new company is my Dad".
Consequently, my understanding is that the lawsuits involved ended in my Dad's favor, but the lawyers were the only ones who profited. My Mom and Dad occasionally argued over the lawsuit. My Dad knew before they filed it that they'd never see a dime and would likely spend money. Nobody thought my Dad was holding out hope for a payout -- he was clear about it from the beginning that it was the principal of the matter. And when he won, I was moved out, but I don't recall being invited to any parties or even hearing about it except in passing. I'm sure it was important, but the thing that I did hear about was when he was able to purchase OldCorp back from the competitor about a decade later.
What was left of his old company's staff was let go and the business was wound down shortly after that. My Dad's business is still around. He's (pretty much) retired; still has the same stake in the company, though they're always entertaining offers to sell. He's had many offers, but none of them came with strong guarantees for the existing staff -- a lot of whom were there day #1 -- and he won't do that to them, they are great people. I think part of it is having a taste of that, himself, when his last company/job disappeared out from under him. Part of it is not wanting to sell the company knowing it's just going to become "a customer list" at a larger company. It won't be the next Google, but I bet he'd love it if it outlived him. I'm sure there are several other reasons, but I know he deeply valued how much his staff was willing to give to his company and that would have been enough.
[0] Mom/Dad played Pinochle and Euchre (Michigan thing) with a large group of couples, Dad played Poker.
[1] If that sounds really vague it's because I was pretty young when this happened, this is not an area I have any expertise in and I've never been sat down and told the entire story from start to finish, so I'm putting together pieces of that memory. But I lived through it as a kid so it's pretty vivid. :)
[2] Not their real name if that's not clear!
[3] Sorry about that -- I try to keep it clean, but that word wasn't said in my house very often, so when 12-13 year old me heard my friend's Dad use it to praise my Dad, it stuck with me. There are times that censoring the profanity loses the effect.
[4] A buddy of mine insisted that my Dad went into the back yelling at them for being behind on something, throwing F-bombs left and right. I spent a few minutes confirming he was talking about my Dad. Growing up, I think I heard him use it four times and Mom twice. When I went to work at a smaller shop in my teens (and every one thereafter in my life), I realize that's not all that surprising ... and that my buddy was also, probably, exaggerating. My Dad was a pilot for a long time and is well known for his cool head; he'd generally swore/yelled at "things" not people (other than the Lions, perhaps, but that's more yelling at the TV).
(Ruin the gag by expaining it, I doubled back at the end and only the saw Jacobian not equal Jacobin : https://jacobinmag.com/ )