4 ms·

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

by 5- 2y ago

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

scarface_74 2y ago
Or in the case of Google at one point had 5 messaging apps shipping simultaneously and talked about three of them at one Google event. Shipping new products shows “impact”. Maintaining and improving existing products don’t.
deleted 2y ago
[deleted]
nosefurhairdo 2y ago
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 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.
- scarface_74 2y ago
  How does that work in organizations where everything has to be tied to a ticket and you have to do pull requests?
  - theamk 2y ago
    You work on what you think is the most important, and then you choose a closest ticket # to put into pull request description. If there is no ticket close enough, then you make one first. Some companies like to micromanage and rob engineers from any sort of autonomy: they have non-engineers make tickets, and those tickets are very small, and they are assigned them without engineer's inputs, and managers carefully monitor that engineers only work on assigned tickets. If that's your case, then I am sorry. Also, it is not not a "senior engineers" position, even if your business card says otherwise. If you are interested in becoming a better engineers, consider a different, less disfunctional, workplace.
    - scarface_74 2y ago
      I agree completely. I’ve been posting about leveling guidelines based on “scope”, “impact” and “dealing with ambiguity” here a lot over the past couple of days. https://www.levels.fyi/blog/swe-level-framework.html https://www.levels.fyi/blog/swe-level-framework.html It was more of a hypothetical question. I haven’t been in that position - ever. But I’ve heard horror stories. As a mid level developer (I’m now a staff software architect at a consulting company, I design and lead implementations from the ground up), do you really have that kind of autonomy to choose the tickets you work on outside of what was put in the sprint? I didn’t when I was a ticket taker a decade ago.
  - toast0 2y ago
    In such an organization, there's no low hanging fruit, because everything requires a ticket writing exercise, and a group consensus managment exercise. Or you make up a blanket ticket, and self-approve your PRs. Or you start probing for process in interviews, so you can find somewhere to work without oppressive process.
    - nosefurhairdo 2y ago
      I'm in such an organization, but this does not echo my experience. I write a ticket describing the work (takes no more than five minutes), open a PR, and get someone on my team to review. The engineers on my team dictate the process because we've repeatedly earned our manager's trust (and he's a great manager).
  - nosefurhairdo 2y ago
    I write a ticket and open a PR and ask my team for review.
ori_b 2y ago
You know what killed the dinosaurs, right? Impact.
- scarface_74 2y ago
  It wasn’t “dealing with ambiguity”???
- slavik81 2y ago
  I was expecting "the ice age". Maybe I'm getting old...
- robertlagrant 2y ago
  Deep.
Artoooooor 2y ago
That's exactly what I facepalmed to. But the higher-ups are still more responsible as they are the ones setting rules. And the rule is: make half-finished thing if you want to get the promotion. On the other hand - engineers should not call something done unless it's really done. Especially in presence of any manager.
bdangubic 2y ago
and yet software eats the world, eh? the craziest thing to me is that each time I get close with someone in our industry (conferences, meetups, socially…) and get insights into what they do and how things are I stop doing something in my life. I sold a car of a certain brand after hearing horror stories about the code running the car and few other things like that… crazy stuff!
pockmarked19 2y ago
I agree with what John Carmack said about that. https://news.ycombinator.com/item?id=26170052 https://news.ycombinator.com/item?id=26170052

by 5- 2y ago

scarface_74 2y ago

Or in the case of Google at one point had 5 messaging apps shipping simultaneously and talked about three of them at one Google event. Shipping new products shows “impact”. Maintaining and improving existing products don’t.

deleted 2y ago

[deleted]

nosefurhairdo 2y ago

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

scarface_74 2y ago
How does that work in organizations where everything has to be tied to a ticket and you have to do pull requests?
- theamk 2y ago
  You work on what you think is the most important, and then you choose a closest ticket # to put into pull request description. If there is no ticket close enough, then you make one first. Some companies like to micromanage and rob engineers from any sort of autonomy: they have non-engineers make tickets, and those tickets are very small, and they are assigned them without engineer's inputs, and managers carefully monitor that engineers only work on assigned tickets. If that's your case, then I am sorry. Also, it is not not a "senior engineers" position, even if your business card says otherwise. If you are interested in becoming a better engineers, consider a different, less disfunctional, workplace.
  - scarface_74 2y ago
    I agree completely. I’ve been posting about leveling guidelines based on “scope”, “impact” and “dealing with ambiguity” here a lot over the past couple of days. https://www.levels.fyi/blog/swe-level-framework.html https://www.levels.fyi/blog/swe-level-framework.html It was more of a hypothetical question. I haven’t been in that position - ever. But I’ve heard horror stories. As a mid level developer (I’m now a staff software architect at a consulting company, I design and lead implementations from the ground up), do you really have that kind of autonomy to choose the tickets you work on outside of what was put in the sprint? I didn’t when I was a ticket taker a decade ago.
- toast0 2y ago
  In such an organization, there's no low hanging fruit, because everything requires a ticket writing exercise, and a group consensus managment exercise. Or you make up a blanket ticket, and self-approve your PRs. Or you start probing for process in interviews, so you can find somewhere to work without oppressive process.
  - nosefurhairdo 2y ago
    I'm in such an organization, but this does not echo my experience. I write a ticket describing the work (takes no more than five minutes), open a PR, and get someone on my team to review. The engineers on my team dictate the process because we've repeatedly earned our manager's trust (and he's a great manager).
- nosefurhairdo 2y ago
  I write a ticket and open a PR and ask my team for review.

ori_b 2y ago

You know what killed the dinosaurs, right? Impact.

scarface_74 2y ago
It wasn’t “dealing with ambiguity”???
slavik81 2y ago
I was expecting "the ice age". Maybe I'm getting old...
robertlagrant 2y ago
Deep.

Artoooooor 2y ago

That's exactly what I facepalmed to. But the higher-ups are still more responsible as they are the ones setting rules. And the rule is: make half-finished thing if you want to get the promotion. On the other hand - engineers should not call something done unless it's really done. Especially in presence of any manager.

bdangubic 2y ago

and yet software eats the world, eh? the craziest thing to me is that each time I get close with someone in our industry (conferences, meetups, socially…) and get insights into what they do and how things are I stop doing something in my life. I sold a car of a certain brand after hearing horror stories about the code running the car and few other things like that… crazy stuff!

pockmarked19 2y ago

I agree with what John Carmack said about that. https://news.ycombinator.com/item?id=26170052 https://news.ycombinator.com/item?id=26170052