6 ms·

The whole start-up culture encourages this behaviour. The current fire fast trend, rather than trying find the root cause for example. Firing someone can compl

by UK-AL 13y ago

The whole start-up culture encourages this behaviour. The current fire fast trend, rather than trying find the root cause for example. Firing someone can completely mess up someones career, but people are being told to fire someone on a whim, if they're not right fit(I mean that could be anything). Turn it around, and put yourself in their shoes.

_delirium 13y ago
It's an odd trend in part because it doesn't seem like companies can afford it. At least, they complain about the results: can't find and keep enough good programmers. If there were a huge pool of easy to find qualified people, just firing people at the first whiff of difficulty, rather than debugging management, could be a viable strategy. But if good people are hard to find, firing a good engineer for "bad fit", rather than first trying to figure out whether the fit is a management issue, seems shortsighted. Or at least, if you take that strategy, I'm not going to have a lot of sympathy for complaints that good developers are hard to find! If this strategy works at all, and companies really can take a haphazard approach to management and succeed with it, it would suggest that good developers aren't really in that short supply after all.
api 13y ago
I experienced "fire fast" on the receiving end once. It's the one and only time I've been let go for any cause from a job. It occurred at a shall remain unnamed big startup on the East Coast. I was hired on the merit of my portfolio and past positions (I do not have a high-snob-factor college degree), and dove in and got up to speed pretty quick. Job was to implement a lot of Java code and some .NET for a major web-based marketing product. Management was completely by the book Scrum, including actual use of terms like "pigs" and "chickens" and such. I roll my eyes at that kind of thing, but I don't really mind and can just roll with it. It's by no means the worst "management design pattern" you could use. The place had a superficially awesome culture, even had a foosball table. Roll eyes a little again, but who cares if it's startup-cliche. It actually is fun so again roll with it. Communication in the team feels good, stuff is actually getting done, etc. One person is a bit of a dick but everyone else seems cool. Nice view from the common office window. I feel pretty good about this job so far. My first and only real hint that anything is amiss is that the code I am tasked with working on is shite. I mean hacky, ugly, uncommented, generally nasty-ass crufty Rube Goldberg machine Java code that takes over a gigabyte of RAM to do trivial things that ought to take under a hundred megs. It's also uninstallable. Just try running it in a dev environment. Seriously. Just try. I had obviously been given the bastard child of a Red Bull fueled late night coding binge to untangle. That's cool. I'm on it. My task, should I choose to accept it, was to add a few features to the product and fix a list of several bugs. Problem #1: this code was so badly written it was incapable of handling the load of current customer demand. Short term solution #1: fire up more EC2 instances. I calculated that for this product alone they were spending almost 1/4 of my salary on EC2 compute instances to compensate for the code's general clunkiness. To do something that ought to be able to be done on a Pentium-4 with a gig of RAM they were running enough EC2 compute nodes to do protein folding on a complete genome. Problem #2: the code was full of static, global, mutable state. This meant that the easy way of reducing overhead by parallelizing things was an exercise in banging one's head on the table. I am told this needs to be done. I start feeling as if I'm getting pressure. Sprint is coming to an end soon. Everything I do fixes this or that problem but the boat anchor continues to suck so bad my demonstrations and tests fail simply on sheer bloat. Fucking nasty-ass sack of crap is so bloated I can't even properly test it on my dev workstation. Fuck it. All weekend coding spree time. I am going to -- wait for it -- rewrite the core. I stay up late all weekend at home doing this, coding furiously, and by Monday end up with a functional core of this product that does the same thing the old one did but used ridiculously less resources. The old version took many EC2 nodes to do what it did, while the new version does the same thing on less than 512mb of RAM on my Macbook and does it in a fraction of the time. Coffee has now supplanted hemoglobin as a principal oxygen/CO2 carrier in my bloodstream. Unfortunately I'm going to have to spend a bit longer to get things done by the end of sprint on Tuesday, but never fear. I have cleared my schedule and plan to stay at the office until all sprint tasks are completed, which should now be do-able without wrestling a greased shoggoth. The meeting is awkward though. I show this to people and I have a strong sense that something is wrong. Later that day I'm called into the office and told I'm being let go, though with a bit of a severance (??? not sure why but I'll take it). Why? (1) Performance doesn't matter. Don't I know anything? "Premature optimization is the root of all evil," even if said optimization saves 1/4 of my salary in compute costs and makes the product instantly responsive. (2) "We don't want to maintain all this new code you wrote" -- but it was less than the old code, I argue, and the old code was... never mind. (3) My favorite: apparently what I did was "not agile," and I would be "better suited for a research position."
- UK-AL 13y ago
  Sounds like a Daily WTF, but it's also very common. Its seems most companies don't realise the easiest way to move fast, is a extensible, easy to change/understand code base. And not going through spaghetti code with a fine tooth comb. Odd they recommended research, they only care about one off prototypes. The problem is future employers assume your the problem. Btw, Proper scrum/agile encourages people to refactor and keep technical debt down.
  - api 13y ago
    Luckily this engagement was so short, and followed after a period of independent consulting, that I was able to be only slightly dishonest and call it a short-term consulting gig. Thing that pissed me off the most was that I was proud of this code. It was elegant asynchronous java.nio-based stuff that used something like 1/100th the RAM and brought the product's response time down from a several hours "we'll get back to you" to less than a minute for small customer sites. It could also run the entire product on one EC2 compute node instead of like a dozen. I also commented it thoroughly and wrote a design document to hand to other developers describing exactly how its central queue based async architecture worked. Every method had a complete JavaDoc comment including the method's "contract," etc. It's actually some of the cleaner code I've written. Not the thing I'm most proud of, but probably on the top ten. Didn't have full unit tests yet, but could have done that in a day or so easily. The second thing that pissed me off was this: I have a strong suspicion based on circumstantial evidence that the fact that my college degree is from a po-dunk Midwestern school had something to do with it. I have a strong suspicion that what I did would have been brilliant if I'd gone to a top-ten university. The founder apparently had such a hard-on for top-ten talent that he wrote about making sure candidates were from "the right schools" repeatedly on his blog, and I got the sense from the get-go that he was skeptical of my hire. Whatever. My career is looking good and I can probably code the guy under the table so :P
    - bonestamp2 13y ago
      > The founder apparently had such a hard-on for top-ten talent that he wrote about making sure candidates were from "the right schools" repeatedly on his blog, and I got the sense from the get-go that he was skeptical of my hire. Fuck these people. I have a fancy degree and I work with better programmers who never even went to college. I work for a client that is very scrumy and I did a huge rewrite/refactor similar to you one week, although probably smaller considering I also delivered the other tasks expected for the sprint. Nobody even cared that the rewrite made the product 10x faster. Nobody cared! But they were ecstatic about other lame changes that were assigned. I think it's because management didn't ask for it to run faster, but they did ask for the other things. The next week I got asked to find out what my changes broke because the app is behaving so much quicker. I had to remind them that I rewrote the slow part and there's nothing wrong. Still, nobody was excited... except me, because now it was a lot easier to develop with because it was faster and easier to debug.
marcosdumay 13y ago
By the otehr side, not firing can completely mess up a small company, but nobody ever likes doing it. People repeat a lot of "mantras" that say you should do something contrary to human nature (fire fast, get shit done, speak in a lot public, try to falsify your hipotesis). They are very important, as human nature dictates the default action every time, we need to be constantly reminded that the default may be wrong, and that we should stop and think about it. But then, stupid people exist, even if they are stupid just a small fraction of the time. And those people will make stupid decisions. There is no procedure, environment, or technique that solves "stupid".

by UK-AL 13y ago

_delirium 13y ago

It's an odd trend in part because it doesn't seem like companies can afford it. At least, they complain about the results: can't find and keep enough good programmers. If there were a huge pool of easy to find qualified people, just firing people at the first whiff of difficulty, rather than debugging management, could be a viable strategy. But if good people are hard to find, firing a good engineer for "bad fit", rather than first trying to figure out whether the fit is a management issue, seems shortsighted. Or at least, if you take that strategy, I'm not going to have a lot of sympathy for complaints that good developers are hard to find! If this strategy works at all, and companies really can take a haphazard approach to management and succeed with it, it would suggest that good developers aren't really in that short supply after all.

api 13y ago

I experienced "fire fast" on the receiving end once. It's the one and only time I've been let go for any cause from a job. It occurred at a shall remain unnamed big startup on the East Coast. I was hired on the merit of my portfolio and past positions (I do not have a high-snob-factor college degree), and dove in and got up to speed pretty quick. Job was to implement a lot of Java code and some .NET for a major web-based marketing product. Management was completely by the book Scrum, including actual use of terms like "pigs" and "chickens" and such. I roll my eyes at that kind of thing, but I don't really mind and can just roll with it. It's by no means the worst "management design pattern" you could use. The place had a superficially awesome culture, even had a foosball table. Roll eyes a little again, but who cares if it's startup-cliche. It actually is fun so again roll with it. Communication in the team feels good, stuff is actually getting done, etc. One person is a bit of a dick but everyone else seems cool. Nice view from the common office window. I feel pretty good about this job so far. My first and only real hint that anything is amiss is that the code I am tasked with working on is shite. I mean hacky, ugly, uncommented, generally nasty-ass crufty Rube Goldberg machine Java code that takes over a gigabyte of RAM to do trivial things that ought to take under a hundred megs. It's also uninstallable. Just try running it in a dev environment. Seriously. Just try. I had obviously been given the bastard child of a Red Bull fueled late night coding binge to untangle. That's cool. I'm on it. My task, should I choose to accept it, was to add a few features to the product and fix a list of several bugs. Problem #1: this code was so badly written it was incapable of handling the load of current customer demand. Short term solution #1: fire up more EC2 instances. I calculated that for this product alone they were spending almost 1/4 of my salary on EC2 compute instances to compensate for the code's general clunkiness. To do something that ought to be able to be done on a Pentium-4 with a gig of RAM they were running enough EC2 compute nodes to do protein folding on a complete genome. Problem #2: the code was full of static, global, mutable state. This meant that the easy way of reducing overhead by parallelizing things was an exercise in banging one's head on the table. I am told this needs to be done. I start feeling as if I'm getting pressure. Sprint is coming to an end soon. Everything I do fixes this or that problem but the boat anchor continues to suck so bad my demonstrations and tests fail simply on sheer bloat. Fucking nasty-ass sack of crap is so bloated I can't even properly test it on my dev workstation. Fuck it. All weekend coding spree time. I am going to -- wait for it -- rewrite the core. I stay up late all weekend at home doing this, coding furiously, and by Monday end up with a functional core of this product that does the same thing the old one did but used ridiculously less resources. The old version took many EC2 nodes to do what it did, while the new version does the same thing on less than 512mb of RAM on my Macbook and does it in a fraction of the time. Coffee has now supplanted hemoglobin as a principal oxygen/CO2 carrier in my bloodstream. Unfortunately I'm going to have to spend a bit longer to get things done by the end of sprint on Tuesday, but never fear. I have cleared my schedule and plan to stay at the office until all sprint tasks are completed, which should now be do-able without wrestling a greased shoggoth. The meeting is awkward though. I show this to people and I have a strong sense that something is wrong. Later that day I'm called into the office and told I'm being let go, though with a bit of a severance (??? not sure why but I'll take it). Why? (1) Performance doesn't matter. Don't I know anything? "Premature optimization is the root of all evil," even if said optimization saves 1/4 of my salary in compute costs and makes the product instantly responsive. (2) "We don't want to maintain all this new code you wrote" -- but it was less than the old code, I argue, and the old code was... never mind. (3) My favorite: apparently what I did was "not agile," and I would be "better suited for a research position."

UK-AL 13y ago
Sounds like a Daily WTF, but it's also very common. Its seems most companies don't realise the easiest way to move fast, is a extensible, easy to change/understand code base. And not going through spaghetti code with a fine tooth comb. Odd they recommended research, they only care about one off prototypes. The problem is future employers assume your the problem. Btw, Proper scrum/agile encourages people to refactor and keep technical debt down.
- api 13y ago
  Luckily this engagement was so short, and followed after a period of independent consulting, that I was able to be only slightly dishonest and call it a short-term consulting gig. Thing that pissed me off the most was that I was proud of this code. It was elegant asynchronous java.nio-based stuff that used something like 1/100th the RAM and brought the product's response time down from a several hours "we'll get back to you" to less than a minute for small customer sites. It could also run the entire product on one EC2 compute node instead of like a dozen. I also commented it thoroughly and wrote a design document to hand to other developers describing exactly how its central queue based async architecture worked. Every method had a complete JavaDoc comment including the method's "contract," etc. It's actually some of the cleaner code I've written. Not the thing I'm most proud of, but probably on the top ten. Didn't have full unit tests yet, but could have done that in a day or so easily. The second thing that pissed me off was this: I have a strong suspicion based on circumstantial evidence that the fact that my college degree is from a po-dunk Midwestern school had something to do with it. I have a strong suspicion that what I did would have been brilliant if I'd gone to a top-ten university. The founder apparently had such a hard-on for top-ten talent that he wrote about making sure candidates were from "the right schools" repeatedly on his blog, and I got the sense from the get-go that he was skeptical of my hire. Whatever. My career is looking good and I can probably code the guy under the table so :P
  - bonestamp2 13y ago
    > The founder apparently had such a hard-on for top-ten talent that he wrote about making sure candidates were from "the right schools" repeatedly on his blog, and I got the sense from the get-go that he was skeptical of my hire. Fuck these people. I have a fancy degree and I work with better programmers who never even went to college. I work for a client that is very scrumy and I did a huge rewrite/refactor similar to you one week, although probably smaller considering I also delivered the other tasks expected for the sprint. Nobody even cared that the rewrite made the product 10x faster. Nobody cared! But they were ecstatic about other lame changes that were assigned. I think it's because management didn't ask for it to run faster, but they did ask for the other things. The next week I got asked to find out what my changes broke because the app is behaving so much quicker. I had to remind them that I rewrote the slow part and there's nothing wrong. Still, nobody was excited... except me, because now it was a lot easier to develop with because it was faster and easier to debug.

marcosdumay 13y ago

By the otehr side, not firing can completely mess up a small company, but nobody ever likes doing it. People repeat a lot of "mantras" that say you should do something contrary to human nature (fire fast, get shit done, speak in a lot public, try to falsify your hipotesis). They are very important, as human nature dictates the default action every time, we need to be constantly reminded that the default may be wrong, and that we should stop and think about it. But then, stupid people exist, even if they are stupid just a small fraction of the time. And those people will make stupid decisions. There is no procedure, environment, or technique that solves "stupid".