12 ms·

Let me tell you about one of my personal stories. The project I got transferred to was the thing of nightmares. Not deterred, I hacked into it a shitty soluti

Let me tell you about one of my personal stories. The project I got transferred to was the thing of nightmares. Not deterred, I hacked into it a shitty solution and shipped it very fast. I shipped it so fast that suddenly I had everyone's attention. And I shipped another thing super fast and got more attention. One day, I said "this needs to go", and everybody listened, architects and directors alike. 6 months later, most of the code was replaced by my code or something originating from it. Every projects and features delivered on time with great appreciation of the clients. You have to make it like software development is not a problem at all in the eye of your client and never never go behind the line where this is not true. The day software development is a problem, you lose. You must deliver software like you're delivering a book from amazon, no matter what. Because then, you got credit to make things better, which creates a positive loop. In that particular instance, I used some rushed victories to get more credits to make things clean later on. The guys who say they can make things clean but never ship and never win any battle against a deadline are just funny anyway. To be honest, I took some fights in my career. I was fighting some dudes in every project. But don't fool yourself: if you're not really capable of making things better, then fighting is useless, just improve. You win the fights because the managers are on your side and you get them on your side by making software development not a problem at all. edited

UK-AL 7y ago
I really don't get your point. How does this help this guy's situation? He couldn't get things released quickly because he couldn't even get the program compilied without serious effort involved.
- huffmsa 7y ago
  If there was minimal code and a lot of the dependencies were unmodified forks of common things, the GP here is likely of the opinion that he should have started ripping the wiring out and replacing it with something that works.
  - UK-AL 7y ago
    That generally takes a while. Not great if you want quick results.
shoshin23 7y ago
I agree with this. Showing results is the easiest way to influence people, especially when it comes to software devs and management. As a manager, I'm more inclined to trust someone who's delivered results even in challenging codebases. It's human.
- indogooner 7y ago
  "trust someone who's delivered results even in challenging codebases" Yes but comparing a guy's productivity when he is demonstrating how difficult the environment is to make progress is poor management. He has already shown the results in previous project.
deleted 7y ago
[deleted]
indogooner 7y ago
Both you and OP are right. May be the codebase you went in could be salvaged. Not true for OP where he has to prepare for a big launch.
mugsie 7y ago
> Not deterred, I hacked into it a shitty solution and shipped it very fast. And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter. You may look good, but the team / dept / company is worse off, and someone else has to clean up.
- deleted 7y ago
  [deleted]
- jacquesm 7y ago
  Well, that depends. You haven't actually seen the product so the assumption that it sucked and needed cleaning up may be a faulty one. I've seen the 10x phenomenon first hand a couple of times and some of those people really are that much better that their 'quickly hacked out solution' still beats your 'carefully considered product of 12 individuals'. In fact some of these simply work better because they are the work of a single talented individual, no meetings, no distractions, no comms overhead or having to explain stuff. Design by committee is rarely better than design by a good craftsman or woman.
  - mugsie 7y ago
    The parent literally said it was a "shitty solution". I agree design by committee can produce awful results - and I said nothing about a single person doing a design as being an issue.
    - koheripbal 7y ago
      People overestimate the duration that their software will be used, so in many cases imperfections aren't as important as a developer might think they are. My last project I released still had about 20 TODOs in the code. I launched it, it got great reviews, everyone loved it, then I got a new project and they deprioritized the "cleanup" phase. I suspect the edge-cases are just getting handled manually - no one cares and I'm still a hero.
      - 7y ago
pdpi 7y ago
> You must deliver software like you're delivering a book from amazon, no matter what. This particular story provides an important refinement to this point. Success isn't always possible. Delivering "no matter what" is part of what engenders trust, but an even more important component is being ahead of the ball. If your manager comes to you saying "you're not matching expectations", whatever explanation you might have will be read as an excuse. If you proactively tell your manager "hey, this framework seems hellish, we might face some problems", you're leading the discussion in how to recover from a bad situation — You redefine "success" early enough in the game that you can actually deliver it. Knowing how to have this conversation (and the self-reflection necessary to understand you need to have it) is one of the most important parts of a "true" 10x engineer.
- quadcore 7y ago
  "hey, this framework seems hellish, we might face some problems" The problem if you think about it is that you will tell him just that every time you see him. In other words, how do you show that you know how to make a good framework other than by beating deadlines? Beat deadlines, again and again, and then you will be granted the right the make a framework yourself. One that. among other things, actually beat deadlines.
  - pdpi 7y ago
    I think you missed my point. "Beating the deadline" means that you deliver something that meets or exceeds expectations within the deadline. You achieve this by pulling two levers: By adjusting expectations and by getting things done. Crucially, each lever only goes so far — you (usually) can't adjust expectations to the point where you're expected to do zero work, and you can't deliver on impossibly demanding expectations solely by working extra hard. While you're absolutely right that the "keep shipping" lever is very important, the article provides an example of where you need to pull the other lever early.
    - granos 7y ago
      I'm currently living this. About a year ago I inherited a large codebase that has been allowed to accumulate tech debt for the past 5 years. This was all done in the name of adding new features and keeping the business competitive. But it's time to pay down the debt. I've had MANY frank conversations with both product and engineering leadership about the current state of the world. The VP of engineering is onboard and understands the pain of what we're going through. Product is a bit harder to convince, but just as important -- probably more important. They understand that my team is having to spend 20%+ of our time just bringing the code into this decade, because I set that expectation early and reinforce it often. I argued AGAINST a from-scratch rewrite because I knew it would never be ok to stop shipping. But I have been able to convince them that slowing down now will let us move faster later.
patientplatypus 7y ago
You shipped hacky software very fast, and you think this is a good thing? Sounds like you got ahead personally at the expense of anyone who had to use what you wrote :/
pif 7y ago
> You must deliver software like you're delivering a book from amazon, no matter what. If you are taking responsibility to maintain it for 15 years, feel free to go on. Otherwise, please step down and let professionals do their work.
- pif 7y ago
  I suppose downvotes are from so-called project managers whothinks that valuable things are created by checking boxes in a spreadsheet.
  - tropshop 7y ago
    More likely from developers who hate to identify as developers because developers like to focus on development problems without empathy for the end result.
yosefk 7y ago
100% true. You don't get to replace a pile of shit or even to call it a pile of shit before you demonstrate that you can navigate the pile of shit and teach it new tricks, otherwise you have no credibility. This of course means, at least theoretically, that a sufficiently big pile of shit never gets replaced (since nobody can (or wants to) be sufficiently productive with it to gain the necessary credibility) and might sink the company which made it. But there's no other way. There are always 10 people telling that the code is shit and the only reliable way to tell that some of them are trustworthy is by observing their ability to get things done in the existing code base.
- dnh44 7y ago
  I think you make a great point but the argument depends on the unstated assumption that master shit navigator == master architect, and I'm not sure how often that's true. They are different skills (maybe?) and while I'm sure there are loads of people with both skills I don't think it's universal. I personally know one engineer that after a decade of being the 10x rockstar shit navigator finally got the opportunity to create a codebase from scratch. They'd been dreaming of doing such a thing for years and had the design all planned out. It was to be the shiny new product for the company. One day the people upstairs finally gave their blessing. The ninja worked alone, making all the decisions, with full support of upper management. The result was a great big steaming pile of shit that nearly sunk the company. After a short period of mental health problems the ninja was promoted to shogun and the company hired a new shit navigator. In football (soccer) it's easy to observe that good players can be good in totally different ways and/or situations. And it's also easy to observe players who were once thought of as good or bad can totally change either way when they change teams. It's a shame engineering performance can't be as easily observed.
karmakaze 7y ago
The story has survivorship bias. I have similar stories that are exactly the opposite. Started on a prohecr, refused to ship crap, shipped the right thing late to the delight of customers and supporting staff. The other main point is that while I'm doing this thing that gained cred and leeway, at the time I'm just trying to do the right thing in the eyes of people who have to deal with it first hand over the long term including maintainers of the software. At no point dud I think if I do this and look good I'll have the points to fix my mess later or any sort of gaming strategy at all.
- dllthomas 7y ago
  It can also go the other way in that your shipping in the face of adversity can be taken as evidence that the adversity isn't actually that bad. And... that's kinda legitimate, although weighting it too heavily is bad.
deleted 7y ago
[deleted]
wbronitsky 7y ago
I find comments like these, which boil down to “stop complaining and hack a solution already” to reinforce the problem identified by TFA, which is that context matters. I feel like OP has elided that fact; the context is that a hacked up solution was acceptable here. That is not always the case, and sidesteps the point that context is king
bongobongo 7y ago
Sounds like you’ve advanced in your career by undermining your teammates and sacrificing professionalism in order to win praise from people who are willing to put systems and users at risk without understanding the co sequences. I understand your point, which basically boils down to the axiom of managing expectations. But sacrificing professionalism is not something that should be accepted as normal, let alone celebrated as clever. It’s the oldest trick in the book.
m463 7y ago
"There is hardly ever lock contention, so I just ignored locks in my coding. It really sped up my deliveries and I got a good reputation for moving quickly. Sure there were some corner cases to clean up later, but by then I had moved onto another project where I moved fast and broke things!" - fictitious person we've all known
timwaagh 7y ago
Let me congratulate you. I'd be very yealous of such an achievement. You probably had things on your side, like being able to ship/deploy when you wanted and cooperative colleagues letting it pass review quickly. As for the 'just improve' part, few people can. Even experienced people like myself who are not at all bad programmers. Some things just take talent.

UK-AL 7y ago

I really don't get your point. How does this help this guy's situation? He couldn't get things released quickly because he couldn't even get the program compilied without serious effort involved.

huffmsa 7y ago
If there was minimal code and a lot of the dependencies were unmodified forks of common things, the GP here is likely of the opinion that he should have started ripping the wiring out and replacing it with something that works.
- UK-AL 7y ago
  That generally takes a while. Not great if you want quick results.

shoshin23 7y ago

I agree with this. Showing results is the easiest way to influence people, especially when it comes to software devs and management. As a manager, I'm more inclined to trust someone who's delivered results even in challenging codebases. It's human.

indogooner 7y ago
"trust someone who's delivered results even in challenging codebases" Yes but comparing a guy's productivity when he is demonstrating how difficult the environment is to make progress is poor management. He has already shown the results in previous project.

deleted 7y ago

[deleted]

indogooner 7y ago

Both you and OP are right. May be the codebase you went in could be salvaged. Not true for OP where he has to prepare for a big launch.

mugsie 7y ago

> Not deterred, I hacked into it a shitty solution and shipped it very fast. And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter. You may look good, but the team / dept / company is worse off, and someone else has to clean up.

deleted 7y ago
[deleted]
jacquesm 7y ago
Well, that depends. You haven't actually seen the product so the assumption that it sucked and needed cleaning up may be a faulty one. I've seen the 10x phenomenon first hand a couple of times and some of those people really are that much better that their 'quickly hacked out solution' still beats your 'carefully considered product of 12 individuals'. In fact some of these simply work better because they are the work of a single talented individual, no meetings, no distractions, no comms overhead or having to explain stuff. Design by committee is rarely better than design by a good craftsman or woman.
- mugsie 7y ago
  The parent literally said it was a "shitty solution". I agree design by committee can produce awful results - and I said nothing about a single person doing a design as being an issue.
  - koheripbal 7y ago
    People overestimate the duration that their software will be used, so in many cases imperfections aren't as important as a developer might think they are. My last project I released still had about 20 TODOs in the code. I launched it, it got great reviews, everyone loved it, then I got a new project and they deprioritized the "cleanup" phase. I suspect the edge-cases are just getting handled manually - no one cares and I'm still a hero.
    - 7y ago

pdpi 7y ago

> You must deliver software like you're delivering a book from amazon, no matter what. This particular story provides an important refinement to this point. Success isn't always possible. Delivering "no matter what" is part of what engenders trust, but an even more important component is being ahead of the ball. If your manager comes to you saying "you're not matching expectations", whatever explanation you might have will be read as an excuse. If you proactively tell your manager "hey, this framework seems hellish, we might face some problems", you're leading the discussion in how to recover from a bad situation — You redefine "success" early enough in the game that you can actually deliver it. Knowing how to have this conversation (and the self-reflection necessary to understand you need to have it) is one of the most important parts of a "true" 10x engineer.

quadcore 7y ago
"hey, this framework seems hellish, we might face some problems" The problem if you think about it is that you will tell him just that every time you see him. In other words, how do you show that you know how to make a good framework other than by beating deadlines? Beat deadlines, again and again, and then you will be granted the right the make a framework yourself. One that. among other things, actually beat deadlines.
- pdpi 7y ago
  I think you missed my point. "Beating the deadline" means that you deliver something that meets or exceeds expectations within the deadline. You achieve this by pulling two levers: By adjusting expectations and by getting things done. Crucially, each lever only goes so far — you (usually) can't adjust expectations to the point where you're expected to do zero work, and you can't deliver on impossibly demanding expectations solely by working extra hard. While you're absolutely right that the "keep shipping" lever is very important, the article provides an example of where you need to pull the other lever early.
  - granos 7y ago
    I'm currently living this. About a year ago I inherited a large codebase that has been allowed to accumulate tech debt for the past 5 years. This was all done in the name of adding new features and keeping the business competitive. But it's time to pay down the debt. I've had MANY frank conversations with both product and engineering leadership about the current state of the world. The VP of engineering is onboard and understands the pain of what we're going through. Product is a bit harder to convince, but just as important -- probably more important. They understand that my team is having to spend 20%+ of our time just bringing the code into this decade, because I set that expectation early and reinforce it often. I argued AGAINST a from-scratch rewrite because I knew it would never be ok to stop shipping. But I have been able to convince them that slowing down now will let us move faster later.

patientplatypus 7y ago

You shipped hacky software very fast, and you think this is a good thing? Sounds like you got ahead personally at the expense of anyone who had to use what you wrote :/

pif 7y ago

> You must deliver software like you're delivering a book from amazon, no matter what. If you are taking responsibility to maintain it for 15 years, feel free to go on. Otherwise, please step down and let professionals do their work.

pif 7y ago
I suppose downvotes are from so-called project managers whothinks that valuable things are created by checking boxes in a spreadsheet.
- tropshop 7y ago
  More likely from developers who hate to identify as developers because developers like to focus on development problems without empathy for the end result.

yosefk 7y ago

100% true. You don't get to replace a pile of shit or even to call it a pile of shit before you demonstrate that you can navigate the pile of shit and teach it new tricks, otherwise you have no credibility. This of course means, at least theoretically, that a sufficiently big pile of shit never gets replaced (since nobody can (or wants to) be sufficiently productive with it to gain the necessary credibility) and might sink the company which made it. But there's no other way. There are always 10 people telling that the code is shit and the only reliable way to tell that some of them are trustworthy is by observing their ability to get things done in the existing code base.

dnh44 7y ago
I think you make a great point but the argument depends on the unstated assumption that master shit navigator == master architect, and I'm not sure how often that's true. They are different skills (maybe?) and while I'm sure there are loads of people with both skills I don't think it's universal. I personally know one engineer that after a decade of being the 10x rockstar shit navigator finally got the opportunity to create a codebase from scratch. They'd been dreaming of doing such a thing for years and had the design all planned out. It was to be the shiny new product for the company. One day the people upstairs finally gave their blessing. The ninja worked alone, making all the decisions, with full support of upper management. The result was a great big steaming pile of shit that nearly sunk the company. After a short period of mental health problems the ninja was promoted to shogun and the company hired a new shit navigator. In football (soccer) it's easy to observe that good players can be good in totally different ways and/or situations. And it's also easy to observe players who were once thought of as good or bad can totally change either way when they change teams. It's a shame engineering performance can't be as easily observed.

karmakaze 7y ago

The story has survivorship bias. I have similar stories that are exactly the opposite. Started on a prohecr, refused to ship crap, shipped the right thing late to the delight of customers and supporting staff. The other main point is that while I'm doing this thing that gained cred and leeway, at the time I'm just trying to do the right thing in the eyes of people who have to deal with it first hand over the long term including maintainers of the software. At no point dud I think if I do this and look good I'll have the points to fix my mess later or any sort of gaming strategy at all.

dllthomas 7y ago
It can also go the other way in that your shipping in the face of adversity can be taken as evidence that the adversity isn't actually that bad. And... that's kinda legitimate, although weighting it too heavily is bad.

deleted 7y ago

[deleted]

wbronitsky 7y ago

I find comments like these, which boil down to “stop complaining and hack a solution already” to reinforce the problem identified by TFA, which is that context matters. I feel like OP has elided that fact; the context is that a hacked up solution was acceptable here. That is not always the case, and sidesteps the point that context is king

bongobongo 7y ago

Sounds like you’ve advanced in your career by undermining your teammates and sacrificing professionalism in order to win praise from people who are willing to put systems and users at risk without understanding the co sequences. I understand your point, which basically boils down to the axiom of managing expectations. But sacrificing professionalism is not something that should be accepted as normal, let alone celebrated as clever. It’s the oldest trick in the book.

m463 7y ago

"There is hardly ever lock contention, so I just ignored locks in my coding. It really sped up my deliveries and I got a good reputation for moving quickly. Sure there were some corner cases to clean up later, but by then I had moved onto another project where I moved fast and broke things!" - fictitious person we've all known

timwaagh 7y ago

Let me congratulate you. I'd be very yealous of such an achievement. You probably had things on your side, like being able to ship/deploy when you wanted and cooperative colleagues letting it pass review quickly. As for the 'just improve' part, few people can. Even experienced people like myself who are not at all bad programmers. Some things just take talent.