Embrace the Grind
141–150 of 320 posts
Re: Embrace the Grind
#142Earlier quoted context omitted.
> 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 r…
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 20…
Re: Embrace the Grind
#143Earlier quoted context omitted.
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.
Hmmm....it landed me as the tech lead for all of IT and development.
Re: Embrace the Grind
#144Earlier quoted context omitted.
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…
Re: Embrace the Grind
#145> For example, I once joined a team maintaining a system that was drowning in bugs. There were something like two thousand open bug reports. Nothing was tagged, categorized, or prioritized. The team couldn’t agree on which issues to tackle > I spent almost three weeks in that room, and emerged with every bug report reviewed, tagged, categorized, and prioritized. Honestly, this is one of those traps a team can fall in…
> 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…
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.
Re: Embrace the Grind
#146This 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...
Re: Embrace the Grind
#147This 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…
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.
Re: Embrace the Grind
#148Earlier quoted context omitted.
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 fi…
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 pa…
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".
Re: Embrace the Grind
#149Earlier quoted context omitted.
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.
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 h…
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.
Re: Embrace the Grind
#150Earlier quoted context omitted.
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.…
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 po…
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.