Embrace the Grind(jacobian.org)
jacobian.org
Embrace the Grind
https://jacobian.org/2021/apr/7/embrace-the-grind/
319 comments
I did that when I first came to Silicon Valley. I went to work for a company which operated a large, for its day, mainframe data center. (Not IBM, UNIVAC). Each time the operating system crashed, which it did several times a day, a "panic dump" was produced, a stack of paper about an inch thick, with a summary and stack backtrace at the top, and a full listing of the contents of memory.
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.
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.
Respect!
Neat. For some reason I find it satisfying to read an example like that where there's actual real tangible work being done with immediate and obvious benefits.
The weird thing about tackling these seemingly Goliath type problems is that at the start it requires a lot of patience to get going and can be demotivating to see no progress or trickle-slow progress, but once you visibly see that the gears are starting to crank, it is very rewarding.
> it takes a special kind of new hire
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.
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.
This resonates with me so much as I was in this position 3 years ago.
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. :)
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. :)
> we want to move from AWS to GCP
Out of the frying pan and into the fire.
Out of the frying pan and into the fire.
Why do you think GCP is worse than AWS? I've used GCP and found it quite easy to start with and the managed instances was a breeze to set up and deploy stuff. I've done it for only small businesses and they were happy with the results too and the easy to use console made things easier to navigate. Maybe the trouble with GCP comes with scale?
I'm strictly against all "cloud" lock-in, but if you're going down that path despite all caveats, then using the #1 cloud provider makes more sense than a third-place competitor from a company that's best known for not having customer service.
Kubernetes is as anti-lock-in as you can get when it comes to cloud platforms. Which makes sense when you think it's the #3 competitor who mostly sponsors it - on the whole, lock-in benefits the market leader, so commoditization works to upstarts advantage.
I recently worked at a single digit billion dollar valuation SaaS provider and we had to run everything on AWS, GCP and Azure, to be where the customers were.
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.
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.
Thank you, appreciate the detailed answer.
> Why do you think GCP is worse than AWS?
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.
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.
The fire is 1/3 of the cost of the frying pan.
The best advice I was given (when I was a new hire, by my manager) was something along the lines of "You're smart, and you aren't burdened by tradition or seniority. If you see something that looks weird or confusing, ask about it! No one will hold it against you, and your point of view may keep us from committing to something more complex than it needs to be."
I've tried to keep that level of intentional naïveté.
I've tried to keep that level of intentional naïveté.
intentional naivete is such a great way to put it, definitely going to use that going forward :)
>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.
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.
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.
> Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars.
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.
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.
I think you can blame "agile thinking" for that and the general laziness in product planning which is so typical of the last 10 years.
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.
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.
It's my pet theory that we have to go back 50 years and do waterfall right.
See http://bawiki.com/wiki/Waterfall.html
See http://bawiki.com/wiki/Waterfall.html
I don't understand why software architect isn't a position in any of the new startup culture tech businesses. The advantage of having an older, very wise and very experienced engineer whose job it is to document, plan and understand all the moving parts of your project would have been invaluable instead of expecting all the engineers who are stressed about hitting deadlines and chasing down memory leaks to do that work on top of their daily requirements.
> The advantage of having an older, very wise and very experienced engineer whose job it is to document, plan and understand all the moving parts of your project
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 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 people who do this job at large companies are called Staff or Principal engineers. One reason startups might be less likely to have them is that they are extraordinarily expensive.
And you can’t cheap out on the role. It’s also really hard to recognize the right kind of person for this without a somewhat Mature engineering team.
The wrong person in this type of role at a smaller company can things back significantly.
The wrong person in this type of role at a smaller company can things back significantly.
Yeah I saw that early in my career at a small company. Smart and charismatic guy in an architect role, impressed technical and non-technical people alike with his knowledge.
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.
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.
The opposite can be a problem as well: a principal or architect who is stuck in their ways or not up to date on the platform will cause a lot of frustration and waste a lot of time. I've seen this unfortunately a few times: highly experienced and generally knowledgeable engineers who are disdainful of mobile platforms and don't feel they need to learn about the details and limitations of the system before pronouncing on technical designs (This especially applies to iOS for some reason IME).
Yeah, there's one principal DS at my company, and he's a net negative. I'm honestly amazed that they have hired him and kept him (which speaks to deeper issues with the company, unfortunately).
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.
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.
I agree 100%. I've been working professionally as a software engineer for almost a decade now. For the past 5 years or so, I've been focusing on improving my understanding of architecture. I don't really want to be a manager or in charge of too many people. I just want control over architectural decisions. My hope is that I can carve out a niche for myself where I am a senior member of a company(or my own company) who still gets to get their hands dirty.
That's because software architecture like that requires knowing what you want, planning, patience, and such. The "thought leaders" of the business are jittering in all directions, busy pivoting, imagineering, and generally behaving like any other particle undergoing Brownian motion. Holding course to something specific would require ... well, it's just not going to happen.
We do: we've identified this is the most important bug; work it till its "done" so we can't task-shift that work till its done. No daily (or less) priority shift.
I've experienced this professionally. It's super debilitating. At some point, the only thing that you are willing to spend energy on is preventing the last fire you're exhausted from just fighting from happening again. I don't know what I'd have done if I didn't have good support from my manager at the time. He cleared a lot of expectations of other deliverables out of the way, so I could stabilize the infrastructure. Now, I know enough to work the politics to give myself room to do this work, but junior me couldn't have done it alone without cracking.
I agree but I wouldn't call it toxic, rather "foolish".
"meteor strike" what a brilliant way to put it. Been struck by a few of those in my time.
One of the most important things I think Kanban[1] emphasizes is that once you eliminate unnecessary bottlenecks, you're left with unavoidable bottlenecks, and this naturally means there will be slack. Explicitly expecting slack time is super useful to allow developers at all levels of seniority to do surprising and necessary things like this that would otherwise never be scheduled.
[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.
[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.
I think the reason people don't like Kanban is there are a bunch of tasks that suck to get stuff over the line and without the "deadline" there's little incentive to help with them instead of just pulling something else off the backlog.
Take this with a grain of salt, because I haven't done Kanban personally, but I think the theory is that if you hard cap work in progress, and everyone is sitting around on their hands, it puts a lot of pressure to eliminate bottlenecks to progress.
I feel like by far the biggest impediment to my productivity is the knowledge that I have a meeting any time in the next two hours. Unfortunately, that's usually the case.
Just had a meeting with some students looking to outsource some dataset validation work. I had them time themselves for a couple hours doing it themselves, and we found that seeing aside am hour a day for a couple weeks will get them through everything... And they'll end up with higher quality data than they'll get from outsourced validation, with a better idea of the pitfalls of the dataset.
Those students are in the wrong career. You can't make good things from data without (metaphorically) getting your hands dirty.
Or maybe they have just learned something—these are students, not seasoned professionals.
Yeah definitely. To be fair, I was kinda harsh, but it's incredibly frustrating to see people ignore core parts of the DS workflow because it doesn't map neatly to cool technologies. Especially when that part is the base for pretty much everything you'll do with data.
>Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars.
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.
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.
Mark Ruffalo dramatised the lawyer who did exactly this in Dark Waters to foil DuPont. Thanks to this grind, we know what DuPont did to pristine West Virginia waterways with Teflon toxic waste.
https://youtube.com/watch?v=yBGi3SzxkKk
https://youtube.com/watch?v=yBGi3SzxkKk
I tend to be verbose in tracking bugs, but poor in tagging, categorizing, and prioritizing them.
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.
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.
Honestly, I’d have approached it differently.
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.
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.
The author's tactic gives them a good sense of the project, common requests, and bugs over a long time period.
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).
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).
I have to agree. There is nothing more demotivating for me than documenting a bug thoroughly, only to have it returned to me two months later as part of a bulk 'we didn't get to this in time' cleanup.
Issues for those teams usually 'best effort' isolation going forward, which compounds the issue.
Issues for those teams usually 'best effort' isolation going forward, which compounds the issue.
Possibly worse is those small bugs that would just take a few hours to fix but never get prioritized, yet they still get pulled up for discussion week after week during whole team grooming-meetings. "what is this bug again?" Accumulating a total of more admin-time than solution time.
And yet this is what several open source projects do, including VSCode. They've even automated the process. If there's no action on a bug for X amount of time it's auto-closed.
A bug left alone long enough grows from an child bug to an adult bug. You're still caring, feeding, and maintaining that bug the entire time.
I think the oldest bug I've raised that's still open is this Webkit one from 2008 [1]. It still gets plaintive comments from various people every few years. A few more and it'll be going off to college.
[1] https://bugs.webkit.org/show_bug.cgi?id=22261
[1] https://bugs.webkit.org/show_bug.cgi?id=22261
Yeah if you're deleting bugs older than 2 weeks then they're just gonna resurface and you're gonna have to classify them later, in an ongoing process lasting however many weeks. Might as well instead grab the bull by the horns and get the beast tamed right here and now.
> Yeah if you're deleting bugs older than 2 weeks then they're just gonna resurface
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 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 can see it cut both ways.
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.
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.
We're doing it in my current company and we lose a lot of valuable data. On top of this, other teams are not encouraged opening a bug anymore because no-one will fix it.
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.
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.
I've found a happy medium is to have a garbage collection section of the backlog. You'll probably never touch it, but having the data can be important.
> 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 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
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
Note: you'll probably want to copy/paste that URL instead of clicking it, because unless something has changed (e.g. browsers not sending referrers), JWZ had/has a Referrer rule that will show something...else for anyone coming from HN.
https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...
https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...
That's half the fun of legitimate opportunities to link jwz's content. :D
Thanks, I'd forgotten all about that, and also why jwz's domain was resolving to 127.0.0.X on my system.
Ahh, the infuriation of seeing the issue you worked hard to document, closed by summarily by somebody that didn't even try to understand.
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.
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.
I'm very late to the discussion here, but I find this to be a terrible approach.
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.
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.
Well, infuriating when you're a client of teams who use this strategy, but it is certainly effective.
> 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.
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”.
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”.
I had the opposite problem. I took to it like a duck to water and then was told to stop because I had “better things to do.” When I asked what they suggested things I had already done. I become so bored it really affected my work ethic. I didn’t like that and eventually quit.
Interruptions are definitely harmful, but if you look at what he did, he could have done it in spite of meetings. What would be bad would be starting it and being told (implicitly or explicitly) not to finish it.
Better to have meetings than to have what you’re doing cancelled several weeks in.
Better to have meetings than to have what you’re doing cancelled several weeks in.
I did an internal transfer and took over from a team that I think had been in this state for some time— it was really the ideal scenario because in many ways I wasn't having to ramp on everything the way a true new hire would, but I still had the clean slate and clean calendar to immediately get a bunch of stale systems upgraded, processes cleaned up, start into writing some documentation, research new tools to deploy, etc. Very invigorating and a lot of progress possible in a short period of time.
I can both see the value in that approach and, having run across things like this situation before, I can also see an unaddressed question in this post (already brought up by the replies, but worth repeating): how is that scenario not a fundamental failure of management, or some kind of dysfunctional organizational dynamic, to not prevent that kind of thing from happening in the first place?
Bug reports aren't exactly sui generis, they don't just mysteriously appear.
Bug reports aren't exactly sui generis, they don't just mysteriously appear.
[deleted]
Truth! Deep work and focus is difficult, expensive with continuous meetings and notifications. So the OP is extra right! Cutting through the noise looks like magic now.
Imagine how the kernel and operating system feels...
I just recently walked past a hotel advertisement display that had blue-screened, so not well
If the meeting is on a calendar ahead of time it's not really an interruption.
Certainly feels like one when I know the context switch is coming and it's scheduled in such a mid morning or mid afternoon slot that the time either side of it isn't long enough to do deep work, particularly when the rest of the team will interrupt me ad hoc to get unblocked on their work. If there were no meeting I can deal with their interruptions and context switch back to my work and get a long enough stretch to concentrate. With frequent meetings in certain timeslots I get virtually nothing done some weeks.
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.
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.
Personally my least favorite time for a meeting is one that interrupts my usual lunch. They should put you on trial at the Hague for scheduling a meeting from 11:00-1:00.
Yeah I don't want lunch interrupted either. But from 11:00 to 12:00. Or preferably 11:30 to 12:00. Or even 4pm to 5pm.
I don’t know how you work, but my schedule of meeting, work, meeting, work definitely feels like the meetings are interruptions.
Especially since they don’t add any value, but that’s arguably a different problem.
Especially since they don’t add any value, but that’s arguably a different problem.
> If the meeting is on a calendar ahead of time it's not really an interruption.
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
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
I don’t know about you guys, but I can’t really keep a sustained bust going for 8 hours anyway. Even if I had no meetings at all, I have to stop for the restroom, tea, food, or even just to give my body a break.
IME, non-intellectual breaks don't break flow the same way as meetings where you need to use, but shift, intellectual focus. Bathroom, short-walk, and coffee/tea/snack breaks, aside from filling important bodily functions that don’t get filled by meetings, provide a pause that seems somewhat akin to a rest between sets in physical exercise.
It’s an interruption from the task you were working on.
Being planned or on a calendar means it’s not an ‘unplanned interruption’, however, anything that takes you away from what you’re doing is, by definition, an interruption.
In some ways it's worse because you will start anticipating the meeting before it starts.
Great idea! Now I just need to get people to schedule their Slack messages a week in advance.
When I joined a mentoring program targeted at recent college grads, I expected to be teaching things like interview prep, resume writing, negotiation skills, communication skills, and how to deliver results in a workplace.
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.
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.
This resonates with me deeply. I can barely get work done most of the time. My "solution" is to leave a company before people get too frustrated with me. Changing companies frequently nets me better pay and more promotions than my harder-working peers, but I haven't felt fulfilled by work in a long time.
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
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 have a similar problem. What's weird for me is that I feel totally useless and undisciplined, but when I look back, I actually do accomplish important things. But if you watched me day to day, it is obvious I'm wasting a ton of time. Not just on work, but on myself as well.
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 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.
This hits home for me.
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.
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.
Sounds like ADHD, speak to your doctor
> 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.
I’m that friend for all of my friends and I wonder how I have any friends left from the number of people I’ve had to say “you’re being a pillock, and this is how you fix it”
Good to know I’m providing a valuable service
Good to know I’m providing a valuable service
Well, for what it's worth, if you haven't been thanked, you deserve it.
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. :)
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. :)
Thanks, one of them has gone from living pay check to pay check and loosing £100 or so a month to putting offers in for his first house after I told him he was “living like a student and needs to buckle down”. we went through his finances and 12 months later he’s nearly a home owner - that’s all the thanks I need
I've experienced this before too! I'll pick up some unrelated project and really enjoy it and gain momentum again. I don't do it very often though, because I feel like I should be working on my main thing. 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.
> 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.
I think being able to sit down and do work is more about removing distractions than improving focus.
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.
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.
Experience? When I find that I have been focusing for many hours on a complex task, it is usually something I slipped into effortlessly, even accidentally. The whole experience is pleasant. On the other hand I have tried on many occasions to force this when it wasn’t forthcoming, and on top of being extremely uncomfortable, it’s never worked.
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 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 think this is pretty different to stating that you can't code for more than 2 hours.
I don't think anyone can instantly snap into being productive on command, all the time.
I don't think anyone can instantly snap into being productive on command, all the time.
No it’s not. Speaking as someone who specifically has this problem: even eliminating all possible distractions does not do the trick.
Which problem exactly? Not being able to sit down and code for more than 2 hours?
It could be that he isn't productive. I have this problem, where if I sit and code for too long I end up just wasting time debugging or writing useless code.
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.
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.
> 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.
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.
Disclaimer: I'm not an IT guy nor I work for an IT company.
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.
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.
If I am working in an open plan office, on a multi-person codebase, with a half built back-end, 7 hours of coding is gonna be hard work.
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.
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.
It might be sustainable for some people, but not for me... the only time I put in those kind of hours of focused effort is in a FAANG interview loop, and that takes so much out of me that I lie down and stare at the ceiling until bedtime :)
>Which problem exactly? Not being able to sit down and code for more than 2 hours?
Yes.
Yes.
I'm not gonna disagree but I want to add a couple things.
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.
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 always had problems sticking to anything, I'd get enthusiastic for a month or two and then I'd get bored. Never could tidy my room etc. Not saying I've anything as severe as adhd but I had trouble with self discipline. At the start of the year I decided to try to develop a good habit, any habit, to persuade myself I could do it. I decided to exercise. I spent the first 6 weeks just with the principal of do 1 situp, or whatever. Something I could do without any effort, at home, to remove any excuse not to do it. I made a tick on the calendar the days I did it so I could see my progress, I praised myself for completion, and I made it the only priority. Don't worry about tidying or eating healthy or whatever, just do that situp every day. After about 6 weeks I was getting out of bed and immediately doing the situp without thinking, I started a proper routine like 10 minutes, still easy. It'll be 3 months next week, so I'm hoping it's actually stuck. When I get to 6 months I want to start adding something like filling the dishwasher before bed. I'm 37 and this is the first time in my life I can say I've been able to do something I'm not obligated to do and don't want to do for a long period.
There's a book called "Tiny Habits" which goes into this more.
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.
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.
ADHD is a difficult topic to discuss on HN. I'll preface this by saying that I'm not doubting your situation, or any other commenter's particular situation. This [section of my] comment is meant to be general:
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.
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.
Well, I guess that like many things, it's a spectrum, and mental health professionals just had to put the limit somewhere ?
You said "This comment is meant to be general." and then quoted and replied to things the commenter shared about themselves.
Your comment makes me think of when they first designed jet cockpits for pilots. It was expensive to modify the planes, so they designed it to the 'average' person.
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-...
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-...
> 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.
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.
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.
It's also a mistake to think that people are static. We can improve ourselves through the expenditure of effort. The reality is like the parent said: there are limits to everybody's abilities, but you'll probably have to work hard as hell to reach yours (not targeting you personally, the general case "you"). If you believe that your present abilities are all you'll ever have then you're wasting what could be tremendous potential out of false self imposed limitations.
Who said anything about not improving, the parent comment believes the ADHD sufferer is simply not working hard enough.
He's trying to show him where his bootstraps are.
He's trying to show him where his bootstraps are.
As someone who suffers from ADHD, the simplicity of this comment really cuts to the heart of it for me: many words are written by PragmaticPup tiptoeing around what is essentially a directive to "work harder".
Unless you're living with ADHD, you really have no business handing out such directives. I was a hardcore meditator for years, arguably the crucible of mind training -- spent months of silent, directed attention in monasteries -- and despite blowing open the doors to some peak states, complete equanimity with all phenomena, and insight into some of the fundamental mechanics of desire and resistance, I was unable to hold any kind of job at all before I bit the bullet and medicated.
The decades of suffering I experienced because everyone around me was pushing this toxic narrative that ADHD was overdiagnosed and most likely a schema of my own failures could have been avoided if my parents just took a hard look at me and took me to a psychiatrist.
Armchair psychiatrists of Hacker News: please stop this irresponsible and dangerous public criticism of your interpretation of mental illness or the state of psychiatry.
Unless you're living with ADHD, you really have no business handing out such directives. I was a hardcore meditator for years, arguably the crucible of mind training -- spent months of silent, directed attention in monasteries -- and despite blowing open the doors to some peak states, complete equanimity with all phenomena, and insight into some of the fundamental mechanics of desire and resistance, I was unable to hold any kind of job at all before I bit the bullet and medicated.
The decades of suffering I experienced because everyone around me was pushing this toxic narrative that ADHD was overdiagnosed and most likely a schema of my own failures could have been avoided if my parents just took a hard look at me and took me to a psychiatrist.
Armchair psychiatrists of Hacker News: please stop this irresponsible and dangerous public criticism of your interpretation of mental illness or the state of psychiatry.
People who are currently struggling can fall into a self limiting mindset. I can attest to that from personal experience. I don't have ADHD, but I can imagine that having it might make you believe that you couldn't improve your attention at all. The reality is that you might just be able to, even though it would probably much harder than for the general population - in the same way that an underweight person would find it harder to build muscle than someone of average build.
From my perspective it's a positive message, not finger wagging at the impaired.
From my perspective it's a positive message, not finger wagging at the impaired.
On the contrary, one of the biggest sources of suffering in an ADHDers life is constantly being pounded with this very message your entire life despite trying your absolute best.
When the vast, vast majority of people are capable of a baseline far above yours, they hold you to their standards mercilessly.
The number of times I've been reduced to tears by this conversation. I'm telling you. This is by far the worst part of it all.
When the vast, vast majority of people are capable of a baseline far above yours, they hold you to their standards mercilessly.
The number of times I've been reduced to tears by this conversation. I'm telling you. This is by far the worst part of it all.
I'm familiar with the experience - not directly from ADHD, but from my own issues. Trying desperately to keep on top of things, running as fast as you can just to stay in the same place. I'm not saying that "ADHD is easy, just don't be lazy lol", but that you may still be able to do a little better than yesterday if you practice the right skills. I'm in no position to hold someone with ADHD to baseline standards, but I would encourage anyone to just try to be a little better than yesterday, every day.
There's also an awful lot of people, as the parent said, who don't have ADHD but still struggle with {focus, attention, willpower} from just not having used it. Those people should definitely be trying to focus harder and shouldn't be led down the path of "focus is innate/unchangeable".
There's also an awful lot of people, as the parent said, who don't have ADHD but still struggle with {focus, attention, willpower} from just not having used it. Those people should definitely be trying to focus harder and shouldn't be led down the path of "focus is innate/unchangeable".
You might, and you might not.
The incentives for me to be better are already as strong as they can possibly be. Not to screw up my health worse, not to lose my marriage, not to lose my job, not to make rash financial decisions. The amount of effort I put into this already is just exhausting.
I'm glad I recognise these days the times when the car is out of gas and people are telling me "if you just turned the key a little harder, maybe the car would turn on" and ignore them.
The incentives for me to be better are already as strong as they can possibly be. Not to screw up my health worse, not to lose my marriage, not to lose my job, not to make rash financial decisions. The amount of effort I put into this already is just exhausting.
I'm glad I recognise these days the times when the car is out of gas and people are telling me "if you just turned the key a little harder, maybe the car would turn on" and ignore them.
At the end of the day, every individual knows themselves better than anybody else does. I'm just relaying that it helped me, even though I was trying really hard to stay afloat and struggling to focus on most aspects of my life, to just practice focusing - working harder wouldn't have done anything because I didn't have the focus to apply to hard work in the first place. I have no idea whether people with ADHD can improve their focus, but there's people out there who think they might be because they can't focus but aren't, and don't realise that focus is a skill you can practice.
The flipside being there are people who are, and it doesn't cross their mind that they might be, and they're spinning their wheels consuming productivity porn in the hopes of finally cracking the code.
I do agree with what you're saying btw. I think you can and should try to improve things, no matter which side of the coin you're on. The crux of the issue is that it's very, very important to understand which side you're on because the advice and strategies are fundamentally very different.
I'm not at all worried about the people who think they might be ADHD. They fall into 3 camps. 1) people who suspect they have it and it's a life changing revelation and they seek treatment ASAP, 2) people who suspect they have it for a long time and are right but for some reason or other never do anything about it and 3) people who don't have it, and don't understand it well enough to realise they actually don't have it
Group 1 sorts itself pretty quick. The trouble is realising you're in group 1!!!! This is why from time to time I talk about it here if its mentioned. Once it clicks it's unbelievable. I'm very interested in helping those people as it's pretty life changing.
Group 2 I mourn for. But at least they can recognise what advice and strategies apply and understanding why their life is how it is. Knowing is half the battle.
Group 3 I'm not worried about at all. It can be such a devastating problem that when it clicks and you can finally connect the dots, you sort of know. For this group the dots will be too few and far between though naturally for everyone there will be some and they'll hum and haw about it and mull it over in their mind before forgetting about it altogether. If you genuinely think you have then you must feel as if there is and always has been something quite wrong with your life. Though you may simply identify with the list of symptoms because it's somewhat vague, and just be unsure as to what it really means. If you actually think it could be an answer to solving a problem in your life you will go for an evaluation. If you don't think it's an answer to solving a problem in your life then almost certainly you don't have it and will just forget about it. You may go for an evaluation and it comes back negative but unearthed a different problem at the cause of some real troubles for you, and that's ok, as it's a differential diagnosis for exactly that reason.
I do agree with what you're saying btw. I think you can and should try to improve things, no matter which side of the coin you're on. The crux of the issue is that it's very, very important to understand which side you're on because the advice and strategies are fundamentally very different.
I'm not at all worried about the people who think they might be ADHD. They fall into 3 camps. 1) people who suspect they have it and it's a life changing revelation and they seek treatment ASAP, 2) people who suspect they have it for a long time and are right but for some reason or other never do anything about it and 3) people who don't have it, and don't understand it well enough to realise they actually don't have it
Group 1 sorts itself pretty quick. The trouble is realising you're in group 1!!!! This is why from time to time I talk about it here if its mentioned. Once it clicks it's unbelievable. I'm very interested in helping those people as it's pretty life changing.
Group 2 I mourn for. But at least they can recognise what advice and strategies apply and understanding why their life is how it is. Knowing is half the battle.
Group 3 I'm not worried about at all. It can be such a devastating problem that when it clicks and you can finally connect the dots, you sort of know. For this group the dots will be too few and far between though naturally for everyone there will be some and they'll hum and haw about it and mull it over in their mind before forgetting about it altogether. If you genuinely think you have then you must feel as if there is and always has been something quite wrong with your life. Though you may simply identify with the list of symptoms because it's somewhat vague, and just be unsure as to what it really means. If you actually think it could be an answer to solving a problem in your life you will go for an evaluation. If you don't think it's an answer to solving a problem in your life then almost certainly you don't have it and will just forget about it. You may go for an evaluation and it comes back negative but unearthed a different problem at the cause of some real troubles for you, and that's ok, as it's a differential diagnosis for exactly that reason.
IMO any chance of there being a constrained and clearcut definition of ADHD went out the window in affluent communities as soon as they started giving people test extensions if they were diagnosed with it.
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.
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.
As someone diagnosed with ADHD a year ago now, the GPs description of their life experiences are pretty textbook ADHD.
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.
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.
If that is enough to be "textbook ADHD" then the definition is even broader than I thought. Being performant when you're focused but having trouble getting there, having difficulty getting basic chores done, etc.? That's just many people in life.
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.
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.
The definition is indeed more specific than that. Don't be silly. The part that is incredibly relatable there is 1) life long inability to get your shit together (not just periodic or some of the time), and 2) a deep seated emotional anguish from being berated by people your whole life for not doing what you're supposed to when you're supposed to.
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.
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 could have written this and I’m on the verge of losing my marriage too. Already lost my career.
All I want is for people to stop thinking that I'm doing this on purpose.
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).
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).
Consider looking into a prescription for Jornay. It's taken at night and kicks in ~10 hours later, and will normally last me the entire work day. I've tried just about everything, using Ritalin for the longest, and I've found Jornay to be the least intrusive when it comes to my attitude, diet and work.
Where can I join / look into such an initiative? I’d love to give back to those following us, just as many before us did.
It's funny. I was talking with the team on a call, yesterday, and one of them was telling me we should hire someone to do "the boring stuff," so I would be free to do "the fun stuff."
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 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.
Different strokes for different folks - and a mix of different types is often necessary.
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 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?
More or less.
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 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 experienced this when I first started learning the piano. When I played the first song I had learned for my sister, she was amazed. "Wow, I could never play like that", she said, "my fingers don't work that way". But when I broke down for her exactly how I'd learned it -- by breaking the song down into manageable chunks of just a few notes each, practicing each chunk with each hand separately many times until proficiency was reached, stringing the chunks together until I could play the whole song separately on each hand, and then bringing both hands together and repeating the entire process all over again -- her amazement turned to a look of disappointment. It was a mix of both realizing that her brother wasn't actually a genius, and a sort of mild disgust that I'd dedicated so much time to this activity.
Yes, which piece was that btw?
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.
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.
I agree. I think pretty much everything (I've seen it with piano, work, exercise) becomes so much easier when you're motivated.
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...
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...
This is basically exactly how "The elements of piano practice" [1] lays it out.
[1] http://www.pianopractice.org/book.pdf
[1] http://www.pianopractice.org/book.pdf
That's actually exactly the method I used! I had trouble finding the book again, so thank you for linking me to it.
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.
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.
A good magician never reveals their tricks.
Very well put down, I learnt an "intermediate-level" piano piece just like that (a very jazzy "fly me to the moon" https://www.youtube.com/watch?v=vW3w8kV-Xmo) without having ever played piano (I do play another instrument, which helps). It took weeks and weeks of grind, note-by-note, repeating hundreds of times to get your finger to synchronise and memorise, but you get there! Great to show off, people think you're a fairly good pianist, but I can play almost literally nothing else haha :)
[deleted]
Most skills tend to look something like this, where dedication and repetition lead to proficiency. Could be piano, chess, video games, programming...
What are some skills like this that are high-leverage--skills that help with lots of other skills?
What are some skills like this that are high-leverage--skills that help with lots of other skills?
Deliberate practice
Critical thinking
Time management
This quote stuck out to me:
> 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.
> 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 wanted to be a professional magician when I was younger, and there’s a single-handed cut that I learned from Daryl Easton (at a seminar he gave at some Holiday Inn). It took me a month or two of solid practice to get it down, but over thirty years later I can just pick up a deck of cards and flip that cut out like it was nothing. I was saddened to learn that he had committed suicide a while back. Every time I do that flourish playing cards with people or whatever I just remember that time when one of the world’s best magicians hung out with me for a few minutes after his seminar just to make sure I had it down.
The key word is marginal. Sadly, software tends to align against art as pushing boundaries is marginal for the return of investment.
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 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 don't think it's that software engineers don't value it. I think we all understand, to some degree, that building resilient, simple software that solves the problem thoroughly requires incredible investment into carefully thinking through the problem and constant upkeep. It's just that we don't want to believe it because getting from 80% to 100% requires boring grind that we'd rather spend building something new and exciting, or because getting from 80% to 100% requires time we could spend building 80% of something else we want to sell.
For me it's that 1) most people won't even care and 2) someone is going to ruin it anyway, eventually.
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.
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.
I suspect a lot of the noticeable difference between Apple products and the normal stuff that most other companies churn out is the zealotry. Steve Jobs was notorious for being zealous about the small details. Tim Cook was notorious for his very high standards for operations, expecting even minor operations problems to be fixed very quickly and very thoroughly. Other companies do pay a little attention to detail, if you're observant you can see small details everywhere [1]. Apple is known for zealously taking it to the next level.
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
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
By the time you grind to get that 100% perfect solution, the number of requirements the business has put on you in your backlog has extended well beyond what you can keep up with. It's not like software engineers are the only actors in a software system. They are reactive to the needs of product development who are reactive to the needs of customers. You have to balance your limited development resources against a constantly changing set of requirements.
So you make trade-offs.
So you make trade-offs.
I was gonna say that!
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?
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?
Yeah agreed. There's a big difference between the base layer utilities and the application layer interfaces.
> YouTube is constantly breaking, probably on purpose to thwart youtube-dl.
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 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.
Personally I don't like facing the work to take something from 80-100% - I envision the potential work and I can see it laid before me, extending beyond the horizon. And sometimes that work doesn't even lead to a certain success.
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 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.
The movie thing is a good example. I remind my kids that some of these movies cost $1,000,000/minute to make. That might be what they make in their lifetime, so it is about that many hours of work per minute (a life’s work).
When you put it that way, that's obscenely expensive. Maybe we should be steering kids toward entertainment that we can create as well as consume because it's not absurdly expensive.
TV became digital and the amount of channels exploded. Yet the amount of eyeballs watching advertisement didn't. So the money spent per TV program minute went down. Enter reality TV.
But stuff like Netflix or Disney+ is quite cheap compared to other forms of entertainment because it is spread over so many viewers.
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.
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.
It does get kind of ironic if you realize that streaming is getting more and more popular. I guess that's a much more cost effective form of entertainment?
Top billed actors may inflate that, unless you consider that they then spend the money on gardeners and stuff and consider them part of the crew.
One of my favorite magicians: Derren Brown
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.
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 used to be a big fan of Derren Brown when I was younger, and I do still like a lot of his work, but he readily admits to deceiving the audience, and the deception includes the explanations he gives for his techniques.
The video you linked to was part of a longer show (The System) which gives an explanation for how this trick was done - he says they kept filming take after take, for 9hrs, until they finally got ten heads in a row.
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".
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".
He wrote Tricks of the Mind and that was a great book. One piece that has stuck with me for ~15 years now is the 20 word series that I can recite forward or backward after spending 5 minutes visualizing them in a "linked list". For example, telephone - sausage - monkey. Vividly imagine dialing a payphone with a sausage. Next up, sausage monkey. Vividly, using all your senses imagine a monkey flinging sausages to the point of absurdity where he's swimming through sausages.
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.
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.
I've done the exact same trick in my mind to remember a sequence -- the "linked list" linking A to B, B to C, etc. It just seemed natural to me, I didn't read it anywhere. If you have the "head pointer", you're probably golden.
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.
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 book covers both techniques (though not in great detail), Memory Palaces are another term for Method of Loci[0] - in my experience it is actually much better and faster, but requires habitually revisiting rooms in order to remind yourself of their contents (this is as quick as mentally walking through a door into a room and glancing around it from left to right). This is easy and fast but it's also easy to forget to do it and then the contents do start to fade. I use the layout of the first house I owned as my "palace", so it's a real place but no longer somewhere I actually go to in real life which helps avoid confusion.
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.
[0] https://en.wikipedia.org/wiki/Method_of_loci
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.
[0] https://en.wikipedia.org/wiki/Method_of_loci
I can build my grocery list in my memory high school and neighborhood. The skip list could be built as an acronym built out of first letters taken from named areas.
> 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.
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.
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.
They both use the word “lazy” to make their quotes memorable. But that’s it. They’re not actually describing real life laziness.
> 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.
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.
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.
> they emphasize the creative aspect far more relative to tech since they're competing over form not function
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.
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.
>* 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.
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.
> Maybe a similar sort of thing with software would be spending time on animations
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.
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.
My secret weapon for bug diagnosis is that when a regression is reported on a system without an automatic bisect tool, while everyone else is trying to reason about the problem with guesswork and code inspection, I sit down and spend 2 hours just bisecting manually (full sync, rebuild and install of old versions of the software). This provides a guaranteed culprit CL, often one that no one guessed, and also a potential bug assignee who's an expert on the problem in question (the author of that patch).
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.
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.
That approach works well for regressions. I’ve used it myself to track down a bug in chrome and, as you say, having no idea how to fix it, I could direct it to the author via the bug tracker. In my case it was fixed within a couple of days. And obviously bisecting chrome is a slow process, but it only took a couple of hours.
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.
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.
However, every time I reason about the problem & debug it, I gain a little knowledge and do it a little faster next time. Bisecting never really gets faster, aside from maybe writing a script.
Definitely agree with that.
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.
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.
[deleted]
> without an automatic bisect tool
At that scale, reading through the commit messages is often enough to narrow it down to a few suspects.
At that scale, reading through the commit messages is often enough to narrow it down to a few suspects.
Heh, my answer is that I just refuse to build or work on systems where bugs aren't always super obvious. If the system gets too complex, I bisect the system.
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.
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.
That's my tactic to blend-in in a engineering team and gain some respect / credibility.
I try to find the most boring, utterly broken part, that nobody wants to touch... and I sink time into it.
Once I made it somewhat usable, I document it.
Once I made it somewhat usable, I document it.
I hadn't realised it til now, but I do the same. It's a really great way to get started, because it tends to coincide with not having yet gained a broad range of responsibilities pulling you in different directions. You become a domain expert in something (which was probably lacking across the team) and peers appreciate it.
After they've seen that, you organically start getting invited to all kinds of more interesting projects and discussions.
After they've seen that, you organically start getting invited to all kinds of more interesting projects and discussions.
I don't like to chime in with "seconding" on HN but I had the same eureka moment about it. I have definitely always behaved like that and it was just a natural and organic way to start in any team or job.
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.
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.
One of my 'secrets of my success' moments was realizing that one of the grind areas I reject has to do with the all of the processes of building the application. You stare at that stuff long enough and you might not know how the application does what it does, but you have a pretty good idea of where it does them.
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).
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).
Same here. I like doing things nobody wants to do, especially when I'm new in the team.
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?
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?
It happens at first. But point to the docs you wrote. Politely, but firmly, every time. People actually prefer being empowered to do it themselves, so they will pick it up, it just not our default when we're unsure.
Except redeploying is something that always must be done last minute in a hurry because the last version deployed has a bug that will explode any moment and launch-demo is approaching, so managements blood hounds are pushing for someone who really knows how to do it to make sure it's done swift and proper!
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.
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 used to be quite happy to do all the dirty jobs that needed doing until I had an epiphany and realised I wasn't getting any credit for this. In fact it seemed to be doing my career some harm.
I stopped and refused any work that wasn't directly linked to bringing money in. Within a couple of years my salary doubled.
I stopped and refused any work that wasn't directly linked to bringing money in. Within a couple of years my salary doubled.
Pair with someone else and have them do it, and be explicit about your intention to share the knowledge.
Never become the guy who can fix the printer.
I think in some ways this strategy, which I also employ, is rejecting the grind, rather than embracing it.
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.
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.
Important distinction you’re making.
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 )
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 )
Some things are just very hard to explain for various reasons. One of them is that it's painful to look at how stupid some processes are.
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.
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.
Good stuff.
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'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.
This strategy is common in any skilled labor trade. For example, joining a carpentry team the first thing you have to do is tote lumber to earn respect.
This is really what it takes to make a quality product. It's not only being able to focus long enough to get the job done, but also having co-workers that also value quality and focus. I get so annoyed with co-workers who don't value quality. Everything has to be done yesterday, quick and dirty, with little to no care involved. And for what? To move on to upper management's other random idea that probably isn't great?
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.
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.
I find there is a general assumption that quality means things will be more expansive, and take longer. To the contrary, I have often times found that a quality driven approach ultimately gets you to the goal faster and cheaper. However there are strong incentives to get ‘something’ working as quickly as possible at the expense of quality. That then sets expectations of the standards of quality that persist.
Something similar can be said of writing survey paper in academia. Nobody wants to go through 150 papers about some godforsaken topic, but the one guy that goes through it is immediately considered to be a top notch expert.
I can really relate to this. Countless times I've run into tasks that are even only minor grinds (some tedious work that maybe takes 30 minutes to an hour to do), and countless engineers I've worked with will just complain, avoid, or just plain be unwilling to do them. They'll indulge in discussing why things are wrong this way, what architecture should be like etc. And countless times, I'll just get through the minor grind and do the thing. Many of these engineers are smarter and more knowledgeable than I am, but when the time comes for performance reviews, promotions, these grinds really count. It's exactly as the author describe it, these grinds look like magic to the audience (management); because they are impactful to the business. Having said that, of course it's no excuse to create or perpetuate poor engineering or architecture by grinding. It's a balance.
Maybe this is a naive question, but why couldn't you just pick a bug at random, fix it, and move to the next? You said eventually you worked through all issues in about a year of time. How did having the issues prioritized from the get go really mattered, if you ended up closing them all anyways?
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?
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?
It's a good question. i.e. if it takes a year to fix all bugs then why does order matter?
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 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.
Human psychology is a thing. If you point a team at a growing pile of bugs that no one has wrapped their head around, then the team will feel demoralized, overwhelmed, and unmotivated. But if someone does wrangle the bug list and produce a plan and strategy for tackling them, then there is hope and mission and maybe you can even get buyin from management for more resources--maybe not headcount, but even just easing the roadmap for a year in pursuit of Quality.
The difference between "nobody has gone through this entire list" and "somebody has gone through this entire list" is huge.
The difference between "nobody has gone through this entire list" and "somebody has gone through this entire list" is huge.
My guess is that the noise of new bug reports was incapacitating the team. You can't fix anything if each few minutes somebody comes to complain about a new problem.
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.
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.
Quite often what happens in these cases is that people get paralyzed looking at the list of open things, and rather than just digging in and doing something to chip away at the pile, there are meetings and discussions and noise which generates a lot of heat and sound and stress, but doesn't actually make any positive progress towards resolving the issues.
An meanwhile things keep getting thrown on the pile.
An meanwhile things keep getting thrown on the pile.
The effort to impact ratio is wildly different among bugs in a large backlog. Sometimes a 10-minute single line change will produce a massive benefit for all users. Other times a developer can slog on a bug for weeks only to realize that no one cares about the fix anymore. You want to start tackling the ones in the first category before spending time on the second.
Partly, yeah.
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.
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.
It might be investing in tackling it, but I would guess that, more than that, it's that one person was tasked with doing it.
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 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.
Some bugs are more important to fix than others. If you rank each bug by effort and impact, you want to fix the high-impact, low-effort bugs first, and the low-impact, high-effort bugs last (if ever).
This article may be the most important article on Hacker News you may read this year.
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.
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.
Its often more complicated than that.
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.
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.
Thanks for sharing this. I think this is a good example of the kind of story we encounter more often.
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.
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 think the core of it is indeed values, but in the Real World it's about printing money. If the natural incentives for "Better Things" are replaced with "Get all the moneys, escape any consequences" then we get the current macro-economic incentives in all domains.
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.
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.
I think the short-term vs. long-term topic is indeed part of it. But that already implies that people actually see and understand the long-term version.
The real magic behind that bug triage anecdote isn't the tedious work it took to get there, it's that a year later anyone noticed, gave a shit, or gave credit where it was due. In 9/10 organizations, such outcomes never materialize because no one is working for the common good, nor cares about silly little things like old bugs. Often there simply isn't time. You are instead being yanked from meeting to meeting, thrashing from one poorly defined management prerogative to another, because no one outside the code base has any understanding of what it actually takes to build a stable product nor do they really care.
Alternate framing: be prepared to "Do Things that Don't Scale" (http://paulgraham.com/ds.html ) when your organization is small.
Not a fan of pg, but his schlep essay is a better alternate framing of this article (if my reading comprehension is accurate...): http://www.paulgraham.com/schlep.html
I had forgotten that the schlep essay was distinct. Interesting that they don't refer to each other.
ah yes, his own submarine topic ;)
http://www.paulgraham.com/submarine.html
http://www.paulgraham.com/submarine.html
This reminds me of a blog post by Steve Klabnik (on the community team of Rust currently) about how he went through the Ruby on Rails backlog once similarly. It's a good read: https://steveklabnik.com/writing/how-to-be-an-open-source-ga...
Thanks! I’m glad you like it; at the time I didn’t think it was a big deal but it’s probably one of the most widely-read things I’ve written... (Tiny nit: I am not on the community team. I am on the core team though.)
Ah dang I knew I should have looked up your role!
> You will be fooled by a trick if it involves more time, money and practice than you (or any other sane onlooker) would be willing to invest.
Ah, this is so good. I think you could swap “trick” for “talent” and this would read just as true.
Ah, this is so good. I think you could swap “trick” for “talent” and this would read just as true.
Ooh, good call. I've had so many people tell me that I'm so talented in various areas that I was previously very _untalented_ (such as swing dancing). It was confusing to me for many years until I realized that the hundreds of hours I agonized over fundamentals paid off in ways that people thought I was inherently _talented_.
And the difference is what? If I have no "talent" on guitar but I practice for thousands of hours until I can "trick" you into thinking you're listening to Hendrix...
I assumed this was from https://www.jacobinmag.com and expected something quite different
I know the author and yes, he gets this a lot...
Glad I wasn't the only one!
What a fascinating story.
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...
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...
What he describes isn't grind, it's taking care of a big mess.
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.
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.
"People said I did the impossible, but that’s wrong: I merely did something so boring that nobody else had been willing to do it."
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.
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.
It's interesting that while this often produces stunning results, it usually doesn't lead to pay increases and promotions.
> it usually doesn't lead to pay increases and promotions
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.
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.
> Companies that don't tend to bleed employees.
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.
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.
Yep, learning to optimize for visibility is one of the things every corporate worker should do.
It's unfortunate, but the main way to actually see your compensation and respect increase.
It's unfortunate, but the main way to actually see your compensation and respect increase.
Doing a good job is important. Pay increases and promotions are obtained through way of leverage, but doing a good job and building a strong reputation pays dividends in the future.
Reminds me of this Penn and Teller trick with a similar method but the opposite effect -- see https://www.youtube.com/watch?v=gnEGedfTrzc (skip to 2 minutes in). Freely think of any card, then miraculously reveal the card in an improbable location. It's "easy", just hide all 52 cards and memorize where they're hidden.
Really well written and so true... I think that far too often, people get intimidated by the size/scope/hairiness of a problem and try to reduce their intimidation by breaking it down.
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.
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.
That was an enjoyable read and a gentle reminder to avoid the shiny tools and just get to work. Thanks for sharing.
Every time I hear about the "Three virtues", I always think "Well, there's 'laziness' and there's laziness". I know when I or someone else is being 'lazy' or lazy. Same thing for the other virtues. This is why we appreciate those who embrace the grind.
I'm not even sure what laziness is anymore, other than being a symptom of something else.
My personal magic trick is learning to speak almost fluently in a second language (Russian) in about a year. However, when people ask me how I do it, they quickly get turned off when they realize it's just a grind. You need to know about 20,000 words in any language to sound fluent, and there is just no way around brute-force memorization. And if you're serious about learning, you need to keep track of how many words you know, and add new words every day, and have a system for review (Anki). Although memorization alone won't teach you a language, it is a necessary but not a sufficient condition. In the beginning it is poring through grammar books and practicing basic concepts until they become second-nature. During the intermediate stages it is taking thousands of native-spoken complete long sentences with audio and building Anki card decks and memorizing them. Yup, memorizing complete sentences with audio. For advanced stages it is laboriously poring over classical literature (Dostoevsky) while having a repertoire of academic dictionaries on hand, manually recording every new word and brute-forcing every sentence, until one day the language opens up to you like magic.
> You need to know about 20,000 words in any language to sound fluent
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
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
Unlike many comments here, this doesn't resonate with me. Grinds have always had some part that benefits from automation. Rarely can the whole thing be automated in any reasonable timeframe, but individuals parts can easily be. Often the magic is that those around me don't even realize that you can partially automate it so they end up thinking I did it all by hand.
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.
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.
The only “trick” is that this preparation seems so boring, so impossibly tedious, that when we see the effect we can’t imagine that anyone would do something so tedious just for this simple effect.
Even magicians who know many tricks will still enjoy the show and appreciate the effort.
Prestige is a great movie about this very topic.
Even magicians who know many tricks will still enjoy the show and appreciate the effort.
Prestige is a great movie about this very topic.
Anyone ever read The Phoenix Project [0] or The Goal [1]?
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...
[1] https://www.goodreads.com/book/show/113934.The_Goal
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...
[1] https://www.goodreads.com/book/show/113934.The_Goal
Here's a tip: if you can put a number on some part of your grind, and you have some colleagues who are competitive, with each other or with the metric itself (i.e. "can't stop, the warning count is not ZERO!!1!) then you can get help grinding.
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.
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 article is very on point and every team benefits tremendously from people who do just spend the time and sleigh the monsters.
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.
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 just finished reading Arnold Schwarzenegger's autobiography and one thing he says frequently is, "reps, reps, reps, reps!". He obviously got his physical gains through many reps but he also says he would never film a stunt scene without rehearsing it at least 10 times.
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.
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.
>People said I did the impossible, but that’s wrong: I merely did something so boring that nobody else had been willing to do it.
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.
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.
Read it anyway and agree that someone taking care of a task that requires technical understanding, but is in itself repetitive and time consuming is often a critical part of some business process. Many times I've witnessed such issues grow over time, slowly and surely reaching the stage mentioned in the piece.
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.
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.
This is so true for every bug tracking system I ever encountered in any company.
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.
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.
This is such a great article. It's the same reason I wrote an assembler, from scratch, by hand, and now I'm writing a fast interpreter in it. Nobody thinks this is a particularly fun thing. :)
Thanks, I enjoyed that.
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
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
> putting crazy amounts of effort in for a simple outcome, that just works
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".
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".
I embrace best tool for the job. Sometimes it’s code, sometimes manual grind or sometimes something 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.
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.
I would argue this is predicated on others not knowing your doing on the days leading to the delivery of the result.
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.
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.
The same advice applies to data science. The menial grunt work of checking data quality etc is some of the most important and often overlooked for the neater work.
Yup. My digging into the data this week made a discovery that we'd been measuring our outcomes incorrectly for six months. That simple discovery is worth incredible amounts of money to the company, but because it's not an ML model, many people perceive it as low-importance work.
Mind you, all those people will be gone from the industry after winter comes, so I only have to deal with this until then.
Mind you, all those people will be gone from the industry after winter comes, so I only have to deal with this until then.
Totally agreed. Sometimes, just putting in the labour is a great way to get it done. I wasted a ton of time last night thinking about how I'd write a scraper to download my bank statements from my damn bank that uses .net postbacks, which may lead to something, but ultimately I just took my damn ritalin and manually clicked and waited for each one. (then wrote a bash script to rename them all with regex and sed :))
Going into off-topic: It's kind of funny that in the "Anatomy of a Scene" for "The Accountant" that is linked in the article they explain that for making the scene, they didn't have Ben Affleck write all the hand writing himself, but instead took a handwriting sample and used that to make a full wallpaper from it digitally.
So they did exactly the opposite of embracing the grind and just simulated it.
So they did exactly the opposite of embracing the grind and just simulated it.
OK, so you spend hours and days sealing threes of clubs into tea packets. But how do you make the volunteer pick the three of clubs during the show?
That's an entire family of tricks called card forces. I used to have a whole routine based on them. Here's a blog post with three of them: https://conjuror.community/best-card-forces/
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 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.
Thanks for the link. Of the three techniques mentioned, one (the entire deck is all the same card) obviously doesn't withstand any scrutiny; one (riffle through a deck and skip to your chosen card when they say stop) feels like it'd be too risky for a trick that took days to set up; and one (the "natural" force) says "please pay us to learn the secret."
I don't think the trick that's the show pony of this blog post has been revealed to us.
I don't think the trick that's the show pony of this blog post has been revealed to us.
The too-risky one is another part of the trick where the magician is putting in a ridiculous amount of time, in that case practicing in front of a mirror.
Or maybe indeed the magician doesn't use any of those. Another aspect of magic I've read in profiles of Ricky Jay and Teller is that they hunt down and pore over old magic books, looking for less-common techniques and setups to adapt.
Or maybe indeed the magician doesn't use any of those. Another aspect of magic I've read in profiles of Ricky Jay and Teller is that they hunt down and pore over old magic books, looking for less-common techniques and setups to adapt.
But still, Penn and Teller often used a rifle-stop force. I think it's because when a trick is explained by a force, you've given up on impressing magicians.
People use card tricks like these in poker games where real money is being bet and there's a good chance of physical violence if people catch you. What makes you think they can't get it good enough for a parlor trick?
Without divulging details, a riffle force has zero risk and can be easily mastered in a day.
The exact mechanics of a force are the point of the post. Also given your handle, I honestly can't tell if you're trolling or not.
The exact mechanics of a force are the point of the post. Also given your handle, I honestly can't tell if you're trolling or not.
The article links to this Wikipedia page, looks like you can "force" the user to pick a specific card.
https://en.wikipedia.org/wiki/Forcing_(magic)
https://en.wikipedia.org/wiki/Forcing_(magic)
That's just trading one word for another! OK, how do you force the audience member to pick a specific card from a deck?
I have to ask - did you read the (quite short) link?
> 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?
> 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?
Two very easy ones that I’ve never had fail in practice:
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
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
He has put in his article a link to the Wikipedia definition of 'Forcing' (and once there, there is a link to a book describing techniques).
edit: sorry, I hadn't refreshed and seen the other 2 replies before I replied myself.
edit: sorry, I hadn't refreshed and seen the other 2 replies before I replied myself.
I don't understand what you comment contributes to my knowledge. The author says that he will explain a magic trick. He says that step one is to XYZ. He does not say how to XYZ. He instead links to a Wikipedia page that says what XYZ is, but doesn't describe how to XYZ in a way that would work in the magic trick. Instead, it links to a book that might say more about XYZ. I am not about to buy that book.
Do you consider that trick to be sufficiently explained?
Do you consider that trick to be sufficiently explained?
I came here with the same question. I couldn't help asking it, but we've both missed the point: "which I’ve further simplified here for clarity". The details of the magic trick aren't relevant, the analogy is about the grind, not the one little deceptive detail about the trick, which could be sleight of hand, suggestion, etc.
Yup, and I see what the author is doing there. That's great, whatever. But if he is illustrating his point by trying to explain a magic trick, and even including a "spoiler warning," I want him to actually explain the magic trick. Otherwise, it's a kind of a comical piece of rhetoric. "Some jobs are like this magic trick I'm about to explain. First, you do something cool that seems like magic. Now you see, magic and work share an element of extreme tedium!"
So you're not about to do the grind. Thank you for so neatly illustrating why it looked like magic to the author's teammates.
Yes.
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
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 want to apply this grinding idea to hard technical challenges that could take many months or even years. For example, neural networks applications. My understanding is that the principles were around for years but the idea was largely dismissed because of poor practical performance. But by grinding, they worked out things about how to initialize and activate etc. that made it work.
Absolutely. I go through pain stalling detail to automate my laptop via Ansible. Spent many many weekends wasting time on small details that most people would not even bother to think about let alone burn hours working on it... but now, I have an environment that I can appreciate as magic. Although in the only person who sees the reveal, I’m happy that I get to be my own magician
What I found in recent times is people that want to automate things that have no idea how they work :)
I'm a junior SWE and doing maintenance or working with legacy software is a big no for me. I realized this is mainly because I can't see the value these jobs would bring to me so I can't motivate myself.
I wonder, what is the motivation for working with these kinds of systems career-wise?
I wonder, what is the motivation for working with these kinds of systems career-wise?
Working with a big legacy code base is an infinite source of teaching and knowledge, especially around system architecture; what works, what doesn't work, how the craziest workarounds can make something impossible possible, how APIs with the best intention got abused over time, value of tests and where to test, how to read code rather than just write code, and so on. Simply it gives you wisdom, rather than you reinventing the wheel to find things out along the way.
I wouldn't want to do it forever but for a junior to try it out at least once is an important life lesson.
I wouldn't want to do it forever but for a junior to try it out at least once is an important life lesson.
I'm a senior developer, and that would be a major red flag for me, which I would remember during our annual feedback time.
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.
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.
Few months ago I posted on HN asking the same thing. The author addresses it pretty well with a good example.
https://news.ycombinator.com/item?id=25010373
One of the best pieces of advice I ever learned was to volunteer for the jobs no one else wants to do. Shitiest job imaginable rears its head? Jump up and wave your hand like a happy idiot. Managers' sigh of relief. Who can compete with that?
This is a great way to end up being the "expert" in PHP, Rails, frontend dev, and other stuff you actually don't really enjoy doing, and have everyone just keep assigning you those tickets instead of lifting a finger to do it themselves. Ask me how I know.
This has been my experience and it has left me feeling kind of rudderless. I want to do a good job, accomplish things, and build a solid reputation (and hopefully make more money) but it ends up feeling like getting punished for doing well.
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.
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.
I know what you mean. It’s hard for me to half-ass things and I hate everyone sitting there with their thumbs up their ass or pretending they’re too stupid to figure something out. All I can say is it try and find a team that’s focused on stuff you want to do and will appreciate your flexibility. Easier said than done.
Hmmm....it landed me as the tech lead for all of IT and development.
Survivorship bias?
Yes. But it is common advice from CEO s and it fits with what my grandmother used to tell me: the boss gets all the shit jobs.
CEOs are not exactly a disinterested party here, are they?
Well, glad it worked out for you, but I am not the first person to find that doing too good a job at undesirable tasks means everyone thinks of you when they want them done.
I'm building a deep learning dataset right now... I feel the grind in my bones.
Any sufficiently unpleasant task is indistinguishable from magic?
I have to wonder what magicians think of the 80/20 rule. The trick probably needs all 100% and the grind it takes to get there.
The 80/20 rule gets interesting when there is competition in the mix. Why should I see an 80% good magician who spent 20% of the time, when I can see the 100% one? Spending 20% of the time thus gets you ~0% of the money.
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.
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.
Having now hand-curated and updated 100s of level mappings for different companies by using a combination of research, leveling rubrics, and crowdsourced submissions on Levels.fyi, this article speaks to me
“Sometimes, programming feels like magic: you chant some arcane incantation and a fleet of robots do your bidding“
I had a different experience solving similar problems.
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.
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.
What toxic relationships?
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.
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.
This is such an amazing and inspiring article. Thanks for writing and sharing.
Love it.
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).
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).
Everybody's other favorite German word: "sitzfleisch".
I thought this was from jacobin.com and I was very confused
I was waiting for the Marxist analysis.
(Ruin the gag by expaining it, I doubled back at the end and only the saw Jacobian not equal Jacobin : https://jacobinmag.com/ )
(Ruin the gag by expaining it, I doubled back at the end and only the saw Jacobian not equal Jacobin : https://jacobinmag.com/ )
For example, no.
tl;dr "If you're too big to do the small stuff, then you're too small to do the big stuff"
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.