Was surprised this comment was this far down. I re-read the YC ask three times to make sure I wasn’t crazy. Dude wrote the whole article based on a misunderstanding.
I wont mention what company, but where I work we've spent about 6 months now with an entire dev team hammering their heads against a wall trying to port our extension to MV3, because the alternative was to lose it entirely at the deadline.
Hacks, workarounds, bad docs, and lately, Google pops up to tell us OSD is kinda sorta a thing you can use, but clearly it's at a basically alpha level of maturity. This latest announcement might seem like a reprieve, but it's even worse than before for us, because now it's clear that OSD is a temporary measure, and now we have promises to fix the actual issues in the future.
As a manager I have no idea how to proceed. Do we solider ahead with OSD like we planned? Wait for them to fix the core issues? We have so little trust in Google fixing things, and a great deal of confidence in them making things worse at this point. If we commit to OSD we might be looking at doing the same level of work again, when they fix the core issues and deprecate it. If we wait for core fixes, we might not get the work done before a nebulous future deadline that could drop on us at any moment.
Google has caused us to burn an absolutely incredible amount of time and money with this. Believe me, we're are footing the bill, and have been for some time now.
I’d like to add RockAuto as a peer to McMaster. It’s auto parts, and somehow uglier than McMaster, but damn if it isn’t the fastest no nonsense website I’ve seen for parts.
I can drill down to a specific part for a specific car in seconds, and see pics of the product, part numbers, specs. It’s lovely.
Admitting I'm wrong or that I screwed up, and likewise praising others when they're correct or have ideas I agree with.
You would not believe how much smoother everything at work is when you learn to recognize early the signs that you're holding on to a bad opinion, or that you're headed towards a fuckup, and just saying it out loud.
The praising / agreeing thing is a bit more complex. I've noticed more recently that people tend to be quick to disagree but remain silent even when they agree with someones opinion.
Specifically calling out when you agree with an idea has some marvellous effects. The silent ones who also agree join in, people who disagree join the fray, and a rough consensus can be reached quickly.
They've yet to master their own 10nm process let alone 7nm. I don't doubt their processes outdo the competitors on actual die shrinkage but they've been having a hell of a time of it.
That's more or less what Steam Greenlight was and one reason why I love it even if it goes by a different name now. I can pick up something interesting, play around with it, and then catch up on it's progress over years.
I've done this with Subnautica, Starbound, Rimworld, and The Long Dark. I don't regret going on a journey with the developers at all.
I feel like Apple's approach to UI/UX is one half care and consideration for the current user and the rest is "training" for whatever they intend next.
The design world at large gave them shit for excessive Skeuomorphism but it really did train a huge group of people young and old how to use a touch screen.
Performance and quality is something you can mentor. I work my ass off to make sure my devs have a plan to get better at their craft and learn from others. If they're not doing well I tell them immediately before it grows into a shitshow.
Bad values is a slightly difference conversation. If the dev has a bad attitude, refuses to improve, lazy, etc then you can only coach that so far before it's time for termination. It sounds harsh but a good managers job isn't just filling seats. You need to make sure the people on your team force multiply each other, and that your best devs are happy enough to mentor the up and comers. Low values people spoil all of that and need to go, even if they're high performers.
I wrote code like a madman and then went into management. I like management, but I understand what the author of this article was getting at.
I had an identity crisis early on doing management. I liked to tell people what to do, because I had a big map in my head of where things should go. Because of this developers sort of organically gravitated to me for guidance even before I had the official job. However, I also liked to write a lot of code.
Once I was promoted to management I quickly realized just how much "not coding" that job requires. I struggled with not coding as much. I struggled with wanting to micro manage my staff. I struggled with wanting to write their code for them. I had juniors on my team and I wanted to snatch the keyboard from them and write their code for them.
The defining moment for me was one day, while watching one of my developers deploy something magnificent, that I realized I don't necessarily like to "build things", I like to "see things built". I like to see people succeed. I like to see a scribble on a napkin become a tangible piece of software. Code was a means to an end for me.
I won't lie and say I don't miss coding full time. I still get right in there when I can, but I step aside when I know my management duties are going to let the team down. One thing I don't feel is guilty about not coding as much anymore.
This starts out well outlining the problem then ends abruptly with "use this magical third party service to make your problems disappear" with no insight into how it's solving the problem.