6 ms·

Also, but rarely: Some engineer wants it bad enough that they just build it -or some version of it- and then some executive gives the go-ahead to invest more i

Also, but rarely: Some engineer wants it bad enough that they just build it -or some version of it- and then some executive gives the go-ahead to invest more into it. At the end of the day, ideas are just ideas. Execution is everything.

3vidence 2y ago
I've learned the value of this. Some people don't realize the value of something unless you show it to them. It's a risk for sure but honestly it keeps me sane vs trying to get 10 people aligned before starting something and then running out of time. People will happily take credit for your work after it works.
- unkulunkulu 2y ago
  yep, an engineer has the power to directly influence the code. This is a strong power. Sometimes just making a PR is enough and a good convincer in and of itself. Use sparingly of course, weigh in time for making the argument, but this is an artifact just as a convincing research, text or a plot. code can be part of the argument.
- sfn42 2y ago
  I once worked on an application that integrated with a third party api. The way it did this was with a large and horrible client library that used a separate db to cache the data. The data was then fetched from the main application and used to rebuild the pages (in the main db) based on this data once a day. The library had lots of problems, and one day it stopped working. I was tasked with fixing it - we had the source code, it was purchased from someone and copied into the repo. I spent most of the week if not more trying to figure out what was wrong, but I couldn't. What I did learn was that this library was some of the worst most pointless code I'd ever seen. So I told the team that I think I can rebuild this thing from scratch faster than I can fix this bug. The intermediate db is pointless and most of the library code is dead, the rest is garbage. I can make a simple little thing that does exactly what we need better, faster and easier. Nope. No bueno, fix what we have. So I spent a few hours over the weekend, less than a workday, building the new solution. Come Monday I had it pretty much working, a few things needed to be done but it already supported the use case. The pages were built correctly, they had the necessary content but some things were a bit messed up, nothing difficult to fix. Showed it to the team, said I want to use this and delete the old stuff - nope. The only half-decent explanation I got was that the client had paid a way too high amount of money for this garbage library and I guess the team lead didn't want to tell them we wanted to throw it out or something like that.
  - skydhash 2y ago
    As soon as the stakeholders have a say in the technical implementation (other than financial and time constraints), you’re in a world of hurt.
  - deleted 2y ago
    [deleted]
  - kstrauser 2y ago
    Sigh. I worked at a shop that was spending months waterfalling a frontend to some background API calls. I finally got annoyed enough to spend a weekend actually implementing the thing as a Django app. There. Done. I got my ass handed to me by management for not going through the proper processes. I learned something that day: I never want to work somewhere that engineers serve the processes and not the reverse. There are some that are good and necessary: like “thou shalt deploy via CD and not SSH into prod to edit code”. There are others that only exist to serve bureaucracy, and those try my patience.
    - hansvm 2y ago
      > thou shalt not live-edit prod Even then, there's some nuance. During an outage, cowboy coding can get you back up and running much faster.
      - kstrauser 2y ago
        Yeah, depending on the particulars of a system. If you're at a startup and report to the CTO, that might be perfectly fine in an emergency. At a company with a few million users, almost certainly not. There's a spectrum of possibilities.
        hansvm 2y ago
        In an emergency, that sort of thing even happens at Google (more for their smaller services, and almost always in the form of auto-LGTM hot-fixes bypassing the normal checks rather than actual live-editing of a script or binary, but even that latter thing happens occasionally). There are checks and controls, but an emergency for a billion users is a big deal.
usehackernews 2y ago
As a PM, I factor this into prioritization. An engineer passionate for a product will lead to better engineering output, increased morale, and feeling of being heard. A motivated, bought-in engineer team is important when it comes to building the ‘high impact’ products. Prioritization isn’t always black and white. These qualitative factors matter and shouldn’t be ignored. As always, you weight it against other trade offs.
- tsunamifury 2y ago
  I’ve been a pm Eng and designer and this sort of patronizing attitude sucks. Look at the end of the day you should be cultivating fellow thought leaders because when you grow up you learn your priorities are more often than not just your own egotistical nonsense and wrong. But you have a lot of phrases to cut others down. Try something different.
  - llamaLord 2y ago
    Sure there were some buzz words in there... But the actual core of the post wasn't patronising at all. Might need to take a step back and ask why your response to that was so strong.
    - tsunamifury 2y ago
      Hundreds of borderline moron PMs. Armies of them.
  - BobaFloutist 2y ago
    Is it actually all that patronizing to say "If your engineer really wants to work on something, you should probably let them"?
darknavi 2y ago
I am very thankful that over the last few years I've built out the headroom on our team to chase "shiny" things that we know customers will want and that we (engineering) want but aren't exactly cookie cutter for our usual planning flow.
kshacker 2y ago
Oh gosh, I did this yesterday. We need to do something, my manager thinks it is too complex and we do not have the time, I have not been able to convince him (I am another manager), and yesterday I told my guy ... if it takes you X days, just do it and we will tell him later. He will find out after the coup and post-facto I can always justify it "oh we had so many other things going on, we never got to talk about this". And my goal is to show that its value is more than the effort we spend with the workaround.
tracerbulletx 2y ago
A lot of my biggest political successes as an engineer are just building something that I know is important and finding someone higher up who has always wanted it done but everyone tells them it's going to take multiple quarters and it never gets planned.

3vidence 2y ago

I've learned the value of this. Some people don't realize the value of something unless you show it to them. It's a risk for sure but honestly it keeps me sane vs trying to get 10 people aligned before starting something and then running out of time. People will happily take credit for your work after it works.

unkulunkulu 2y ago
yep, an engineer has the power to directly influence the code. This is a strong power. Sometimes just making a PR is enough and a good convincer in and of itself. Use sparingly of course, weigh in time for making the argument, but this is an artifact just as a convincing research, text or a plot. code can be part of the argument.
sfn42 2y ago
I once worked on an application that integrated with a third party api. The way it did this was with a large and horrible client library that used a separate db to cache the data. The data was then fetched from the main application and used to rebuild the pages (in the main db) based on this data once a day. The library had lots of problems, and one day it stopped working. I was tasked with fixing it - we had the source code, it was purchased from someone and copied into the repo. I spent most of the week if not more trying to figure out what was wrong, but I couldn't. What I did learn was that this library was some of the worst most pointless code I'd ever seen. So I told the team that I think I can rebuild this thing from scratch faster than I can fix this bug. The intermediate db is pointless and most of the library code is dead, the rest is garbage. I can make a simple little thing that does exactly what we need better, faster and easier. Nope. No bueno, fix what we have. So I spent a few hours over the weekend, less than a workday, building the new solution. Come Monday I had it pretty much working, a few things needed to be done but it already supported the use case. The pages were built correctly, they had the necessary content but some things were a bit messed up, nothing difficult to fix. Showed it to the team, said I want to use this and delete the old stuff - nope. The only half-decent explanation I got was that the client had paid a way too high amount of money for this garbage library and I guess the team lead didn't want to tell them we wanted to throw it out or something like that.
- skydhash 2y ago
  As soon as the stakeholders have a say in the technical implementation (other than financial and time constraints), you’re in a world of hurt.
- deleted 2y ago
  [deleted]
- kstrauser 2y ago
  Sigh. I worked at a shop that was spending months waterfalling a frontend to some background API calls. I finally got annoyed enough to spend a weekend actually implementing the thing as a Django app. There. Done. I got my ass handed to me by management for not going through the proper processes. I learned something that day: I never want to work somewhere that engineers serve the processes and not the reverse. There are some that are good and necessary: like “thou shalt deploy via CD and not SSH into prod to edit code”. There are others that only exist to serve bureaucracy, and those try my patience.
  - hansvm 2y ago
    > thou shalt not live-edit prod Even then, there's some nuance. During an outage, cowboy coding can get you back up and running much faster.
    - kstrauser 2y ago
      Yeah, depending on the particulars of a system. If you're at a startup and report to the CTO, that might be perfectly fine in an emergency. At a company with a few million users, almost certainly not. There's a spectrum of possibilities.
      - hansvm 2y ago
        In an emergency, that sort of thing even happens at Google (more for their smaller services, and almost always in the form of auto-LGTM hot-fixes bypassing the normal checks rather than actual live-editing of a script or binary, but even that latter thing happens occasionally). There are checks and controls, but an emergency for a billion users is a big deal.

usehackernews 2y ago

As a PM, I factor this into prioritization. An engineer passionate for a product will lead to better engineering output, increased morale, and feeling of being heard. A motivated, bought-in engineer team is important when it comes to building the ‘high impact’ products. Prioritization isn’t always black and white. These qualitative factors matter and shouldn’t be ignored. As always, you weight it against other trade offs.

tsunamifury 2y ago
I’ve been a pm Eng and designer and this sort of patronizing attitude sucks. Look at the end of the day you should be cultivating fellow thought leaders because when you grow up you learn your priorities are more often than not just your own egotistical nonsense and wrong. But you have a lot of phrases to cut others down. Try something different.
- llamaLord 2y ago
  Sure there were some buzz words in there... But the actual core of the post wasn't patronising at all. Might need to take a step back and ask why your response to that was so strong.
  - tsunamifury 2y ago
    Hundreds of borderline moron PMs. Armies of them.
- BobaFloutist 2y ago
  Is it actually all that patronizing to say "If your engineer really wants to work on something, you should probably let them"?

darknavi 2y ago

I am very thankful that over the last few years I've built out the headroom on our team to chase "shiny" things that we know customers will want and that we (engineering) want but aren't exactly cookie cutter for our usual planning flow.

kshacker 2y ago

Oh gosh, I did this yesterday. We need to do something, my manager thinks it is too complex and we do not have the time, I have not been able to convince him (I am another manager), and yesterday I told my guy ... if it takes you X days, just do it and we will tell him later. He will find out after the coup and post-facto I can always justify it "oh we had so many other things going on, we never got to talk about this". And my goal is to show that its value is more than the effort we spend with the workaround.

tracerbulletx 2y ago

A lot of my biggest political successes as an engineer are just building something that I know is important and finding someone higher up who has always wanted it done but everyone tells them it's going to take multiple quarters and it never gets planned.