Embrace the Grind
jacobian.org
jacobian.org
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. :)
Out of the frying pan and into the fire.
Total cloud spend was in 2 digit millions per year.
Many hundreds of k8s clusters, all using each providers k8s managed service.
My general high level take is this:
* AWS
Products mostly work quite well. Their UX is terrible and very inconsistent between products. But things mostly work, and their support is generally excellent, especially when you have a TAM (Technical Account Manager) who you can reach out to at any time. They will help you navigate any support issues, and ensure you get a quick resolution. But AWS stuff is generally very complex, overly complex in my opinion.
Also at scale API rate limits just kill you, and AWS continues to struggle to provide any real visibility into API rate limits. I'm told that large services internal to AWS have to work around this by building their own caching layer in front of any control plane APIs. Also the api limits are at the account boundary, so you have to start doing account sharding.
GCP:
Has better UX, more consistent experience. Much better visibility into limits and things like that. You still probably end up having to do project sharding at scale to work around limits. We continued to run into a lot of issues with GCPs load balancers blackholing traffic, and it was never really resolved. I think their support is generally worse than AWS. I've had substantially worse support experiences with GCP than AWS at 2 companies now. Mostly support not being particularly useful, and not resolving the issue. As a customer it feels like Google has struggled to adapt their culture to the needs of real enterprise customers. AWS has this much more figured out. But my GCP account teams have always been quite good.
Azure: The worst of all 3. Lots and lots of issues with their k8s service, low limits on the number of nodes you could deploy. k8s 1.18 supposedly fixed a lot. But their answer was always just that you have to upgrade. Their support engineers were frequently gave us actively bad advice that would have resulted in full customer outages if we'd followed it. The engineers on my team fortunately didn't listen and instead figured out how to fix issues themselves. Also frequently ran into various limits and you need to start thinking about subscription sharding.
Of the 3, I personally prefer using and interacting with GCP. But their support or is still certainly worse than AWS. That said, I always felt bad for our TAMs at AWS. It felt like a non-stop job where you had too be available at all hours to deal with unhappy customers. They usually gave us fantastic support, but I wonder at what personal cost.
Because the identity model is worse than IAM, and the quota system is insane. The global VPC networking being nicer doesn't make up for this, unfortunately.
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.
The problem being. People don’t want to hear that it’s going to take them a while to get from 0 to 100%. They’d rather hear they can get from 0 to 99% in a day, then spend a month slogging through that last percent.
The wrong person in this type of role at a smaller company can things back significantly.
Now that I have more experience I realize he was more excited about cargo-culting big tech practices than about making sure our software was well-architected. We wasted so much time enthusiastically implementing his low-impact but technically exciting ideas.
A bad principal/staff person has around the same level of impact as a bad manager/director, except it tends to cause more technical badness than social badness.
[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).
Issues for those teams usually 'best effort' isolation going forward, which compounds the issue.
I mean, maybe not—you might lose the users impacted by the bug. Which from a company PoV is probably a loss, but depending on how broken incentives are may not be for the dev team.
I won’t argue that my way is the only correct way because I’m certain it’s not.
Something I didn’t make clear in the very brief description I gave was that, yes, capturing context of what was there is important.
That said - the two projects I worked in where we did this were filled with bad bugs (a separate and problematic issue).
Nothing really replaces spending time with users. That’s what I tend to opt for - figuring out what sucks in their experience and iterate on that.
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
https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...
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.
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.
I'm also fairly certain I have ADHD.
And moving jobs terrifies me because I do pretty well in my current job, and my current job is a good long term one due to the freedom (and somewhat paradoxically some restrictions... it works out really well) it gives me.
> 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.
Good to know I’m providing a valuable service
I've avoided many mistakes due to my friend's sobering assessment of things and I've done the same--though arguably much less so--for him.
At the same time, he serves the opposite purpose, too. He'd build up an idea that he saw value in, which others missed, and would go all-in on it. He frequently referred to the biblical idea that "iron sharpens iron". It's not really the way people operate, but if you're willing to sign on, it'll change your life. :)
> Maybe I just need to be honest with my managers/co-workers and say that I can't focus on my project and I need some quick wins to get back to being productive.
My usual approach would be to say "I'm stuck on a few things with this project, but I have some ideas -- I just need to try them out on something simpler, so here's what I'd like to do" and follow with a well reasoned argument that serves more than my own sanity as its benefits. Most of the people I've worked for don't require much in the way of an explanation[1] but a few have been difficult -- but I solved that by changing positions since this only happened to me at the global telecom I worked at (it was also a small factor in my accepting a position at another company[2]).
[0] For various reasons -- sometimes it was written in a language that I wasn't familiar enough to understand the more advanced usages of it, sometimes it was just really complex code that I fully understood the design/code behind each of the pieces, just not "as a single thing".
[1] With no real correlation between "dev" and "non-dev" managers. I've had non-dev managers that are very receptive because they trust me, and they recognize they don't have the knowledge to challenge my conclusions, and I've had non-dev managers that think manufacturing widgets and writing code are perfect metaphors. I've had dev managers that hear the first part of the argument and say "do what you need to do" and dev managers (usually less experienced) who believe there's no difference between a small CRUD app and a globally distributed, multi-threaded access auditing, requesting and provisioning system.
[2] I hesitate to mention it -- the gentleman involved was a fine manager, he just didn't work with any of the technologies that my expertise was in at the time. Over the last decade, I ended up studying the things he had expertise in, and I'd be willing to bet this factor would have gone away, entirely, had I already had this expertise.
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.
I don't think anyone can instantly snap into being productive on command, all the time.
Maybe I'm just another uneducated recent college grad, but I really don't see how you can work 7+ hours a day and actually be productive. Doing different kinds of work or taking frequent breaks, possibly. But not just sitting and staring at your computer for 7 hours.
Ironically the only way I can be productive for that long is to do the opposite of what you're describing. Focus on a single problem or piece of work, take minimal breaks and sit at my computer for most of the day.
I've only ever done this for bursts of time before though (And never for a company, too many distractions), because how can you be spending so much time building without thinking? It has to be a large, well defined problem. But that doesn't really exist unless you're just copying something or you've already put in the work to define it.
In saying that, I don't think 2 hours is really long enough to make much progress on something. That would only leave me with about an hour of productive time.
Btw, if you're a recent college grad I'm probably around the same age as you.
There is a third option. You are working and staring at the screen for the whole day, even without breaks, but you can't actually focus on a single problem or piece of work, because the manager keeps distracting you.
I work for a small company, and as a consequence, I have a quite wide area of responsibilities.
I can't really focus on the bigger tasks (like creating user's manual for the new company product) when I'm supposed to drop everything if there are any unanswered emails from the client.
And learning midday that "Hey, man, the newsletters have to be ready today! And the website content needs to be updated before you send the newsletters!" is a very likely possibility, too.
Conversely, if I have full ownership over the codebase, built from scratch, 7+ hours will fly by. However, there generally always comes a point where it becomes hard work again.
Yes.
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.
I've also tried to use this when building my own habits and it's been fairly successful. When most people want to start something they get all excited about it and jump in with both feet. And then they burnout and stop. It's the New Years Resolution gym effect. After New Years, gyms are full of people who set a goal to exercise 5 days per week. After 3 weeks the gym is back to normal as all those people burnt out and realized they couldn't keep it up.
The brain needs time to adjust to change. I'll start out with something really simple like exercising one day per week for 15 minutes. Then after a few weeks when it starts to feel routine, I'll add another day and wait a few weeks. Eventually I find that I reach this equilibrium point where the time I'm putting in is enough and it's easy to maintain that habit.
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.
And things like this:
"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."
Are just insanely tone deaf things people without ADHD wind up saying to ADHDers because they have the capacity to do those things and haven't experienced not having the capacity to do them.
Ultimately, I don't really trust the psychology field to determine what is a mental illness and what isn't. It wasn't that long ago that being gay was in the DSM.
It does terrible things to your health, finances, employment and relationships.
My difficulty with basic chores almost cost me my marriage, and I spent north of 1000 nights in the last 5 years doing the dishes at 2am dead last before going to bed because that was the only circumstance under which I could get myself to do them.
I think most people misunderstand it greatly because their frame is "can't focus" but that's pretty nebulous. A better frame is "having a disastrously shitty batting average on choosing what to direct your attention towards or away from". The chronic understimulation leads to engaging predominantly in things that provide enough stimulation, which often aren't what you're supposed to be doing, and getting locked in that mode because anything else pales in comparison so switching away feels almost painful.
Best metaphor I've come up with to describe the difference is imagine you had to live your whole life with no shoes. Imagine all the surfaces you've ever had to walk across and how that would have been without shoes. You'd be fairly reluctant to make transitions between certain surfaces due to the discomfort. So the routes you take would change. Some routes would lead you to not wind up at your intended destination due to needing to walk on a comfortable enough path. You'd always take longer than other people to get places.
Also it's not a mental illness, it's a neurodevelopmental disorder.
I say that as someone who definitely has something neurodivergent going on, as I do not know other people who get excited and have to pace around the house flapping their hands.
The result is that no one fit in it.
Expectations that other people can perform like you do if they just put their mind to it is so blind to the reality of human experience that it's hard to respond.
https://www.thestar.com/news/insight/2016/01/16/when-us-air-...
I never claimed that was the case. In fact, I specifically cited examples where no amount of hard work could close the gap to top performers.
I wasn't suggesting that everyone can perform equally if they just work hard enough. The point is that attention, focus, and work ethic are not static traits of an individual. Yes, we pivot around certain biological attributes, but that doesn't mean they're fixed.
We all benefit from putting in the work to improve our attention spans and other learned behaviors, regardless of our starting baseline.
He's trying to show him where his bootstraps are.
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).
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.
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?
> 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.
My point is that I think you do need to be kind of a zealot about it to be comparable to Apple. Most companies and employees aren't prepared to be zealots about it, which isn't that surprising to me because it's a lot of pressure and effort. One might admire how efficient Amazon is at retail compared to everyone else without admiring the sweatshop-style labor evidently needed to achieve it.
[1] aside: there's a fun Twitter feed for this kind of stuff https://twitter.com/littlebigdetail?lang=en
So you make trade-offs.
curl and ffmpeg are definitely commendable "100%" FOSS projects, but they aren't chasing new features. HTTP3 is big, but it's not like curl had to break HTTP 1.1 compatibility to add it. AV1 is big, but it's not like MPEG1 will ever change. Both projects deal in protocols, which means most of their requirements are literally set in stone, or silicon.
Whereas youtube-dl is constantly breaking _only_ because YouTube is constantly breaking, probably on purpose to thwart youtube-dl.
Why spend the other 80% of my time adding armor plating and documentation to a feature that will either be gone or half rewritten next week?
I don't think they're trying to thwart youtube-dl, because there's so many low-hanging-fruit countermeasures that they don't employ. youtube-dl can download a playlist with hundreds of videos at 1000x playback speed. You can't tell me that's not distinguishable from regular users going through the website.
What's more likely IMO is that the constant changes that ytdl is catching up with are caused by good old CADT (Cascade of Attention-Deficit Teenagers) inside Google, driven by their infamous "build over maintain" culture.
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.
I remember Madonna getting a lot of grief over a statement about climate change because her crew was shifting so much kit around by air. But the reality is someone paying $100 for a concert ticket isn't going to cause much in the way of carbon emissions, certainly nothing like buying a car or a trans-Atlantic flight.
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".
You just created a mental linked list that you can traverse from either direction, and that you'll remember for as long as you want to. Push it to the extremes, build up your method of loci to arbitrary lengths, build your memory palaces and become Hannibal Lecter.
When I told a colleague about this years ago, he said that my approach seemed so much more complicated and/or difficult than his approach (IIRC it's called the Memory Palace?) of building a castle/cathedral / museum in your mind, and as you walk through it, you see a banana on the left, and then a monkey a little further down the hall, then a trombone on the right, etc. For me, that technique simply doesn't work, as much as I try.
The linked list idea works well and arguably lasts longer, but it's also much more time consuming to "set up" (for me at least), and suffers from O(N) time complexity just like a real linked list (i wonder if it would be possible to construct a mental skip-list!) and if I forget a single association then the whole remainder of the list is forgotten.
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.
Totally agree, and IME that's par for the course for any creative endeavor that becomes profitable but unpredictable, whether its cinema, music, or software engineering. I meant more that the final product is judged on aesthetic qualities more so than in software, so the industry naturally allows for more creative expression at the highest levels of decision making.
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.
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.
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?
15 minutes earlier corporate sent out an email about their values and how important knowledge sharing is! Right after deployment is done the work on documenting or automating the process is put at the bottom of the backlog since it's highly unlikely we have to do this in a such a rush again!
Make sure you have some kind of handover agreement in writing that you can point to when this happens. It sucks to be the "i told you so" guy but in situations like this you really need to protect your own back and as you say be very firm on not doing the job next time.
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 )
But like the rubber duck technique, sometimes trying to 'document the bullshit' connects some dots in your brain and lets you either avoid the most frustrating part or at least chip away at it. And sometimes chipping away at a problem gets other people to contribute as well. Hope is a powerful thing.
It's kind of a Hail Mary Play but even the 'bad' outcome is far better than inaction.
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 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.
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.
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.
Ah, this is so good. I think you could swap “trick” for “talent” and this would read just as true.
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.
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.
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.
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
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.
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'm glad my employer has hack weeks twice a year when I can play, or grind out useful-but-low pricey tasks.
I love this image
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.
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".
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.
Mind you, all those people will be gone from the industry after winter comes, so I only have to deal with this until then.
So they did exactly the opposite of embracing the grind and just simulated 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.
> An example of equivocation can be as follows: A performer deals two cards on a table and ask a spectator to select one. If the spectator chooses the card on the left, the performer will hand the card to the spectator. If they pick the card on the right, the performer will take that card as his own and have the other card be the spectator's. In either case, the spectator receives the intended card.
Or maybe you're asking more precisely exactly which forcing mechanism would be used, for the trick in TFA?
1. Get them to tell you to stop as you flip through the cards vertically, and then sleight the card from the bottom of the deck instead.
2. A simple counting trick like this https://youtu.be/ekPbMhJGYmc
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?
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 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.
Of course, it's easy enough to say that hard work is its own reward or that it'll pay off in the long run but it sure doesn't feel that way sometimes.
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'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/ )