4 ms·

A fantastic list. I find #11 to be especially critical to one's career growth: > How to give up your baby, that project that you built into something great, so

A fantastic list. I find #11 to be especially critical to one's career growth: > How to give up your baby, that project that you built into something great, so you can do something else This is the only way to really scale oneself, while growing others in the process. Hanging on to a project indefinitely can rob you of an opportunity to tackle bigger, more challenging problems. It's so easy to get stuck on a comfortable track, feeling like (and probably being) an indispensable subject matter expert, while the bigger fish get away, often without being aware of them or having the necessary bandwidth to even consider their existence. This, in my mind, is one of the big differences between a senior and a staff engineer (where such distinctions exist). I highly recommend this article on "giving away your Legos": https://review.firstround.com/give-away-your-legos-and-other-commandments-for-scaling-startups https://review.firstround.com/give-away-your-legos-and-other.... Have shared it with many senior engineers that were looking to grow to the next level. Oh, and +1 to the author's book "The Manager's Path". Best one I've seen for anyone looking to go down that road.

sopooneo 5y ago
Agree completely. I failed greatly at #11 at my last job. And payed for years. And absolutely second your endorsement of The Managers Path. If anyone here has ever read a “management” book and been baffled by how stupid it was, know that this book is very much a different breed.
godelski 5y ago
This also seems to be one of the biggest things I've seen small but great open source projects mishandle. As the userbase becomes larger they need to hire more devs but that means not having as much control and others doing things that you did before. Learning to delegate (#3, #8, #9, #10, #12, #18, #20, #22) is a really difficult task (because it takes all those points). It is the transitioning from an mostly an engineer and partly a manager to mostly manager and maybe engineering that many engineers find difficult.
secondcoming 5y ago
#11 is probably true in the general case, but for me I am the only engineer in the company on a revenue-based bonus scheme due to my ownership of a pet project. It also doesn't stop me from working on other things. Obviously, if the company have the impression that 100% of your time needs to be on X then that's bad and they're probably getting that impression from you yourself.
H8crilA 5y ago
You'll really understand this business once you get to the point where you can't wait to give up the "grown up baby" to some junior who will be stuck with it for some time to come. Of course only internally, showing such attitude makes getting rid of an overexploited project harder.
- Vinnl 5y ago
  Perhaps that is the reason people try to hold on to their babies — otherwise they get tossed someone else's baby.
Cthulhu_ 5y ago
I'm very much afraid of that one on my current project. I'm a solo developer on the front-end part of an application, I've been asking for people to help me out, and even suggested raising money and opening up a can of consultants (I used to work as one, I know some good ones that can give this project a boost). But on the other hand, I've been working on this for a year and a half now. Objectively it's not that much code yet, I guess (in the 10K LOC region), but I'm just afraid all of my technical choices will be overridden. Mind you, I also try to use ADRs (architecture decision records), which basically force me and others to think about and defend a decision - something I've always missed in any project I've been in.
cout 5y ago
I thought this was a pretty bland list until I spotted that one. I find it very insightful.

sopooneo 5y ago

Agree completely. I failed greatly at #11 at my last job. And payed for years. And absolutely second your endorsement of The Managers Path. If anyone here has ever read a “management” book and been baffled by how stupid it was, know that this book is very much a different breed.

godelski 5y ago

This also seems to be one of the biggest things I've seen small but great open source projects mishandle. As the userbase becomes larger they need to hire more devs but that means not having as much control and others doing things that you did before. Learning to delegate (#3, #8, #9, #10, #12, #18, #20, #22) is a really difficult task (because it takes all those points). It is the transitioning from an mostly an engineer and partly a manager to mostly manager and maybe engineering that many engineers find difficult.

secondcoming 5y ago

#11 is probably true in the general case, but for me I am the only engineer in the company on a revenue-based bonus scheme due to my ownership of a pet project. It also doesn't stop me from working on other things. Obviously, if the company have the impression that 100% of your time needs to be on X then that's bad and they're probably getting that impression from you yourself.

H8crilA 5y ago

You'll really understand this business once you get to the point where you can't wait to give up the "grown up baby" to some junior who will be stuck with it for some time to come. Of course only internally, showing such attitude makes getting rid of an overexploited project harder.

Vinnl 5y ago
Perhaps that is the reason people try to hold on to their babies — otherwise they get tossed someone else's baby.

Cthulhu_ 5y ago

I'm very much afraid of that one on my current project. I'm a solo developer on the front-end part of an application, I've been asking for people to help me out, and even suggested raising money and opening up a can of consultants (I used to work as one, I know some good ones that can give this project a boost). But on the other hand, I've been working on this for a year and a half now. Objectively it's not that much code yet, I guess (in the 10K LOC region), but I'm just afraid all of my technical choices will be overridden. Mind you, I also try to use ADRs (architecture decision records), which basically force me and others to think about and defend a decision - something I've always missed in any project I've been in.

cout 5y ago

I thought this was a pretty bland list until I spotted that one. I find it very insightful.