15 ms·

Disclaimer: I have an MBA. Dalton's full of shit. I could just as easily write a diatribe about developers who think of themselves as special snowflakes, futu

Disclaimer: I have an MBA. Dalton's full of shit. I could just as easily write a diatribe about developers who think of themselves as special snowflakes, future unicorn founder/CEOs, worthy of extremely high compensation and autonomy, yet have zero clue about business, can't deliver a finished product to save their life and have no appreciation for the importance of usability when it comes to creating a product aimed at users who don't have a CompSci degree. During my stint as CTO of a dot-com back in 1999/2000, I realised that there was a lot I didn't know about running a business, strategy, marketing, business development, finance, cash flow planning, accounting, cap tables, negotiation and all the other little things that add up to a successful venture. So, I decided to go to business school. But guess what? A lobotomy wasn't on the curriculum. I can still knock together a shell script, tail -f a logfile and pipe it through grep, get some vague clue about why something crashed by casting my eye over a Java exception error, and make a lazy developer deeply uncomfortable when he realises that - would you believe it! - this particular MBA actually knows what exception handling is and wants to know why the fuck we're not doing it. Going to business school and getting an MBA added many new arrows to my quiver but it didn't take any away. It didn't narrow my horizons - it broadened them. The idea that an MBA can never be of any value to anything other than a large corporation is as ridiculous as the idea that a coder who learnt Java and the Waterfall method at college will never be able to learn Objective C and cope with Agile. True, some won't be able to but that doesn't mean that all won't. MBA curricula are often perceived as out of date because the content must be approved as part of the academic accreditation process. As a result, they often don't incorporate the latest business methodologies. Whether that's a good or a bad thing depends on whether the latest business thinking is merely a fad or something that will last as long as Clayton Christensen's theory of disruption. But, either way, graduating from business school doesn't mark the end of the learning process. My copy of Eric Ries' "The Lean Startup" occupies the same shelf as "Strategic Management" by Saloner, Shepard and Padolny, "Let Me People Go Surfing" by Yvon Chouinard, "Against The Gods: The Remarkable Story of Risk" by Peter L Bernstein and John W Mullins' "The New Business Road Test". My last two Kindle purchases were Brad Feld's "Startup Communities" and "Four Steps to the Epiphany" by Steve Blank. Dalton claims that, "to an MBA Strategy > Implementation" but it's truer to say that, to an MBA, Strategy comes before Implementation. To do the reverse, implementing blindly and pivoting wildly, is akin to blindly throwing darts at a dartboard - eventually one of them will end up in the bullseye but that isn't necessarily proof that the thrower is anything other than lucky. Dalton's entitled to his prejudice. If he wants to take the shortcomings of a subset of MBAs and apply those as a stereotype across the entire population, that's his prerogative. However, to make broad, sweeping generalisations about someone based on a single fact - whether it's the fact that they have an MBA, what school they went to or the colour of their skin - is pretty foolish because the exceptions will bite you on the ass. For every lame MBA, there's a Sheryl Sandberg or Alexis Maybank. For every team of MBA founders with all the strategy and no product, there's a Matthew Prince and Michelle Zatlyn, who came up with the idea for CloudFlare at Harvard Business School[1], or a Neil Blumenthal, who attributes much of Warby Parker’s success to his and his co-founders’ experiences at business school, which Blumenthal described as "the most helpful and useful of any of my educational background."[2] And, for every lame MBA, there are likely dozens of developers who scoff at the notion that building a successful company requires anything other than the ability to code, and certainly none of that crap they teach you in business school. Of course, if that were true, we'd have many more billion-dollar startups and far fewer founders making schoolboy errors that could have been easily avoided. Maybe if Dalton had taken a few classes in strategy and marketing, Wired wouldn't be writing about "The Great App.net Mistake".[3] [1]: http://www.cloudflare.com/our-story http://www.cloudflare.com/our-story [2]: http://pandodaily.com/2013/08/29/warby-parker-the-result-of-a-perfectly-calcuated-mba-machine/ http://pandodaily.com/2013/08/29/warby-parker-the-result-of-... [3]: http://www.wired.com/gadgetlab/2013/08/the-great-app-net-mistake/ http://www.wired.com/gadgetlab/2013/08/the-great-app-net-mis...

ChristianMarks 13y ago
this particular MBA actually knows what exception handling is and wants to know why the fuck we're not doing it. Be constructive and civil. Instead of congratulating yourself for the transitory sadistic, self-righteous pleasure you obviously derive from making the developers you hired "deeply uncomfortable," try working with them. Teach them exception handling if you know this. That would demonstrate a collaborative team spirit. Update: I was downvoted, as expected. In that case, I neglected to add "offensively smug." The humorless business attitude of dog-eat-dog with a facade of righteousness is here to stay.
- unethical_ban 13y ago
  Your comment was akin to "Fix your attitude, you asshole". Let me rephrase your comment to something you would approve of: --- >this particular MBA actually knows what exception handling is and wants to know why the fuck we're not doing it. It's not fun to be berated at work in front of colleagues, and the purpose it supposedly serves can be accomplished by taking the role of mentor, not drill instructor. Don't you think that's a bit harsh? It's a bad mistake for a coding expert to make, but perhaps coding wasn't their first skill, or they had a bad teacher. Call them out legitimately with their faults, let them know that certain best practices are required, and move on. Or even better: If the organization is large enough, have a coding standards document in place, like the Linux kernel and other large software projects do.
- shubb 13y ago
  Working with a technically competent people manager can be awkward, but I think it's over all a positive. The fact is, only the people actually implementing a project can know what the reality is. There are times when a technical tradeoff gets made (for specific example, turning exceptions off entirely in C++ is actually pretty widespread for various reasons, good and bad). Sometimes, that tradeoff may even be wrong in hindsight - a legacy of an earlier iteration that there was never budget to correct. In that sort of situation, a technical person on the outside of the project trying to be helpful can come across as annoying. They are likely telling you what you already know. However, many of these problems actually originate in people management land, and need a people management solution. For instance, I think a lot of projects mess up because they are trying to achieve too much with too little budget, or because no one with the right skills for a particular task is on the project. The people manager needs to solve those problems. It takes an unusually humble programmer to say 'Hey, I've mostly worked in python, and now I'm needing to write all these C++ modules for optimization, I'm in over my head'. If the people manager can understand his skill gaps and hire to fill them, that's really valuable. Similarly, if you need to explain to your boss that 'In hindsight, the way we are doing this won't scale. I need a whole lot of money to rewrite, and you won't see a single new feature for a month', it's going to be a much better conversation if he has understood how and why things got that way, rather than feeling a betrayal of his trust in the guy who's job it is to understand tech stuff. So, being able to say 'we should be handling exceptions' is important, but as a people manager, it is actually probably your fault. They are probably not doing it because you insisted they implement 'that important feature absolutely by next week'. If you are in charge, it's worth remembering that at some level, it's usually your fault.

ChristianMarks 13y ago

this particular MBA actually knows what exception handling is and wants to know why the fuck we're not doing it. Be constructive and civil. Instead of congratulating yourself for the transitory sadistic, self-righteous pleasure you obviously derive from making the developers you hired "deeply uncomfortable," try working with them. Teach them exception handling if you know this. That would demonstrate a collaborative team spirit. Update: I was downvoted, as expected. In that case, I neglected to add "offensively smug." The humorless business attitude of dog-eat-dog with a facade of righteousness is here to stay.

unethical_ban 13y ago
Your comment was akin to "Fix your attitude, you asshole". Let me rephrase your comment to something you would approve of: --- >this particular MBA actually knows what exception handling is and wants to know why the fuck we're not doing it. It's not fun to be berated at work in front of colleagues, and the purpose it supposedly serves can be accomplished by taking the role of mentor, not drill instructor. Don't you think that's a bit harsh? It's a bad mistake for a coding expert to make, but perhaps coding wasn't their first skill, or they had a bad teacher. Call them out legitimately with their faults, let them know that certain best practices are required, and move on. Or even better: If the organization is large enough, have a coding standards document in place, like the Linux kernel and other large software projects do.
shubb 13y ago
Working with a technically competent people manager can be awkward, but I think it's over all a positive. The fact is, only the people actually implementing a project can know what the reality is. There are times when a technical tradeoff gets made (for specific example, turning exceptions off entirely in C++ is actually pretty widespread for various reasons, good and bad). Sometimes, that tradeoff may even be wrong in hindsight - a legacy of an earlier iteration that there was never budget to correct. In that sort of situation, a technical person on the outside of the project trying to be helpful can come across as annoying. They are likely telling you what you already know. However, many of these problems actually originate in people management land, and need a people management solution. For instance, I think a lot of projects mess up because they are trying to achieve too much with too little budget, or because no one with the right skills for a particular task is on the project. The people manager needs to solve those problems. It takes an unusually humble programmer to say 'Hey, I've mostly worked in python, and now I'm needing to write all these C++ modules for optimization, I'm in over my head'. If the people manager can understand his skill gaps and hire to fill them, that's really valuable. Similarly, if you need to explain to your boss that 'In hindsight, the way we are doing this won't scale. I need a whole lot of money to rewrite, and you won't see a single new feature for a month', it's going to be a much better conversation if he has understood how and why things got that way, rather than feeling a betrayal of his trust in the guy who's job it is to understand tech stuff. So, being able to say 'we should be handling exceptions' is important, but as a people manager, it is actually probably your fault. They are probably not doing it because you insisted they implement 'that important feature absolutely by next week'. If you are in charge, it's worth remembering that at some level, it's usually your fault.