Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Embrace the Grind

jacobian.org

Post reply on HN
Print view View original

311–320 of 320 posts

Re: Embrace the Grind

#311

Post by pixiemagic »

pitspotter wrote: post #259
dorkwood wrote: post #213

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 profi…

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 amo…

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...

Re: Embrace the Grind

#313

Post by titanomachy »

mdip wrote: post #196
titanomachy wrote: post #166

Earlier quoted context omitted.

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…

> what would you tell someone a bit further along in their career who still has the same problems? If it's been going on for a while but you are otherwise successful at the work you're doing, the best advice I can give you is to ask a trusted third-party (friend[0], therapist/mentor that you've worked with for a while) and ask them "why, do you think, I have these problems?" Obviously, this has to be someone who won'…

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.

Re: Embrace the Grind

#314

Post by CRConrad »

legerdemain wrote: post #88
wott wrote: post #70

Earlier quoted context omitted.

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.

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 consid…

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.

Re: Embrace the Grind

#315

Post by scriptkiddy »

heterodoxxed wrote: post #142
jokethrowaway wrote: post #113

Earlier quoted context omitted.

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…

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 wo…

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.

Re: Embrace the Grind

#316

Post by hinkley »

dopidopHN wrote: post #73
hinkley wrote: post #24

Earlier quoted context omitted.

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…

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…

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.

Re: Embrace the Grind

#317

Post by unbalancedevh »

rufius wrote: post #78
jldugger wrote: post #45

> 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…

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'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.

Re: Embrace the Grind

#318

Post by kakkan »

kelp wrote: post #276
kakkan wrote: post #254

Earlier quoted context omitted.

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 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 produc…

Thank you, appreciate the detailed answer.

Re: Embrace the Grind

#319

Post by mdip »

titanomachy wrote: post #313
mdip wrote: post #196

Earlier quoted context omitted.

> what would you tell someone a bit further along in their career who still has the same problems? If it's been going on for a while but you are otherwise successful at the work you're doing, the best advice I can give you is to ask a trusted third-party (friend[0], therapist/mentor that you've worked with for a while) and ask them "why, do you think, I have these problems?" Obviously, this has to be someone who won'…

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.
You're right; I wouldn't necessarily use those exact words, but back when I was at a large telecom, my entire job was made up of projects that I created while being briefly burned-out on something else (usually on time outside of the 40-hour work-week). The additional upshot is that it often led to great improvements in whatever I was stuck on, because I'd pick a project that had a related design complication/issue where that issue was easier to solve/reason about[0].

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.

Re: Embrace the Grind

#320

Post by sebelk »

alfiedotwtf wrote: post #240

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 :)
Post reply on HN