Earlier quoted context omitted.
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 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.
Embrace the Grind
231–240 of 320 posts
Re: Embrace the Grind
#232Earlier quoted context omitted.
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 p…
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 "D…
Re: Embrace the Grind
#233Earlier quoted context omitted.
> 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…
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é.
Re: Embrace the Grind
#234The 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.
Mind you, all those people will be gone from the industry after winter comes, so I only have to deal with this until then.
Re: Embrace the Grind
#235Earlier quoted context omitted.
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 h…
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.
Re: Embrace the Grind
#236Well, 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.
Re: Embrace the Grind
#237Earlier quoted context omitted.
If the meeting is on a calendar ahead of time it's not really an interruption.
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.
Re: Embrace the Grind
#238Earlier quoted context omitted.
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 h…
> 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…
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.
Re: Embrace the Grind
#239> 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…