11–20 of 86 posts
Another way to frame this is to not get too attached to your code. Tmrw it could be the cornerstone to a new line of business or it can be burned in the dumpster.
You're asked to demonstrate "ownership", but at any moment some person above you can take all your work away and make you do something entirely different.
Somehow we're asked to care about our work and not care about it at the same time.
> If you ship a project and your management chain begins talking about the next thing, stop improving that project. and this type of advice is precisely why the whole industry completely lost its ability to produce usable things.
> If you ship a project and your management chain begins talking about the next thing, stop improving that project. and this type of advice is precisely why the whole industry completely lost its ability to produce usable things.
I know the code and effort involved, and sometimes just doing the thing is fast enough it's not worth working it into planning. It also keeps me motivated on whatever "next thing" I'm working on when I allow myself some non-next-thing work.
However, there's definitely wisdom in aligning priorities with the business. If "next thing" is deemed more important by the people who pay you, you should probably be focused on that.
Another way to frame this is to not get too attached to your code. Tmrw it could be the cornerstone to a new line of business or it can be burned in the dumpster.
And this is one reason this industry can be so soul crushing. You're asked to demonstrate "ownership", but at any moment some person above you can take all your work away and make you do something entirely different. Somehow we're asked to care about our work and not care about it at the same time.
If you ship a project and your management chain begins talking about the next thing, stop improving that project. In my experience, continuing to work on an already-shipped project is a very common mistake. Declare victory and walk away!
Take some pride in your craft sheesh
The advice here is a super red flag. This isn’t what I want to see from my team at all. I’m glad this advice worked for someone but this path could easily set someone up to be seen as unreliable / untrustable.
I was given high impact projects precisely because I crushed tickets as a junior. I demonstrated repeated mini-competencies (crushing tickets), gained credibility, then got to demonstrate macro-competency (deliver projects). Definitely agree that "crushed many tickets" is less effective in performance review than "delivered critical project". I'm not sure how one gets to be responsible for a project without first cru…
I don't think that 'crushing tickets' is a good metric of developer competency, but it's a very visible metric regardless and is therefore probably a good way to progress in many organisations.
I was given high impact projects precisely because I crushed tickets as a junior. I demonstrated repeated mini-competencies (crushing tickets), gained credibility, then got to demonstrate macro-competency (deliver projects). Definitely agree that "crushed many tickets" is less effective in performance review than "delivered critical project". I'm not sure how one gets to be responsible for a project without first cru…
I skipped the whole junior developer thing. I was hired at a company as a computer operator based on a prior years internship. I was the only one that knew how to code and they got a contract where they needed to build an entire connected double entry verification data entry system with about 10 screens and a management console. I wrote the entire thing in C in the mid 90s.
Unfortunately, after working at another company for 9 years after that, I became an expert beginner by 2008 and didn’t start learning best practices until 2012-2014 at my 4th company.
So in other words - “don’t do that”.
> If you ship a project and your management chain begins talking about the next thing, stop improving that project. and this type of advice is precisely why the whole industry completely lost its ability to produce usable things.
Surely there's a balance to be found. Personally, I allow myself some not-explicitly-requested improvement work when I see what I view as low hanging fruit. I know the code and effort involved, and sometimes just doing the thing is fast enough it's not worth working it into planning. It also keeps me motivated on whatever "next thing" I'm working on when I allow myself some non-next-thing work. However, there's defin…