7 ms·

> According to one former SoundCloud Berlin employee, a lack of direction from Wahlforss, who served as chief technology officer, made things worse, with some e

by xfer 9y ago

> According to one former SoundCloud Berlin employee, a lack of direction from Wahlforss, who served as chief technology officer, made things worse, with some engineers going rogue and rebuilding their colleagues’ work in their preferred programming language. Does this happen at other startups?

Mikushi 9y ago
Happens everywhere. In corp I've seen engineers go behind their manager's back to write something in their favourite language knowing it would've been rejected if discussion had happen beforehand.
- reustle 9y ago
  That sounds like a reasonable reason to fire someone
  - WJW 9y ago
    That depends on how well it works. If it blows up and costs the company a million bucks you get fired, if it works extremely well then you are a maverick genius. "Ask for forgiveness, not permission", etc. Not saying that the extent to which it was apparently done at soundcloud should be acceptable though.
    - sgt101 9y ago
      The extent indicates anarchy which indicates poor leadership. The issue must have been with the management culture - flat hierarchies don't mean free for alls!
  - sgt101 9y ago
    It depends on the outcome of the discussion - which depends on your capability as a manager. Sometimes this behavior is because the manager is an arse who can't run a reasonable process of team decision making, and the covert development is a reasonable appeal from someone who is disenfranchised in the decision making process and is making a very valuable point. The employee so doing is highly engaged and valuable and firing them is an act of self harm. In other cases this is an act of aggression by an unreasonable and arrogant individual who doesn't care about the team or the company and is simply doing what they want. You have to judge - call it wrong (either way) and you have a problem that will cost you dearly. But be aware there are two sides to this coin and you might be the one that needs to learn. My questions are always : is this part of a pattern (conflict, poor performance, bad behaviour?); why don't I want to sit with this person for 2 hours with a coffee and understand whats going on?; why didn't the coffee heart to heart work out?
- elmar 9y ago
  I think most of google sucesses outside search were done like that without the CEO having knowledge.
  - dzhiurgis 9y ago
    I was about to say the same, but it’s not exactly the same. You are free to build anything, but using existing stack. Not pickup new stack and rewrite something that’s not even broken. That said, probably more often than not, there’s an actual value in it.
    - elmar 9y ago
      I think reality is more serendipitous, ny view is that if you have hardworking creativy people working on side projects sometimes magic happens. For example: Android was a completely diferent tech stack from google.
      - din-9 9y ago
        Android was bought in though.
        elmar 9y ago
        I heard in a lecture of Blitzscaling with Eric Schmidt that google founders got the Google Chrome and Android projects running inside google without him knowing the real breath and intentions of the projects. https://www.youtube.com/watch?v=hcRxFRgNpns https://www.youtube.com/watch?v=hcRxFRgNpns
        sgroppino 9y ago
        The main difference could be that google has loads of cash to burn trying things out. I don't know their history 100% but suspect they were pretty strict with standards when they were a small start up.
  - tanilama 9y ago
- pjmlp 9y ago
  And then they go and write a blog entry about how much productive they are now, instead of what was the actual business impact if any, to the company customers or revenue.
  - bartread 9y ago
    ^^^This. And too often little consideration is given to impact further down the line. E.g., does this tie up your development teams in future doing non-value-adding work to fix breaking changes? What effect does this have on ongoing support costs? How easy is this skillset to hire for? How does this fit in with our roadmap? But it doesn't matter because I've bolstered my CV and by the time those things become really painful I'll be long gone. </cynicism>
  - Dylan16807 9y ago
    I don't follow. If they are coding the right things, then a real increase in productivity means better business impact. If they are coding the wrong things, then language doesn't matter. How can a programming language choice hurt the business through some mechanism other than productivity? You could say that such a behavior is "indicative of poor choices" but that's begging the question.
    - pjmlp 9y ago
      No it doesn't mean a business impact at all, unless it is proven by accounting. Programmer hourly rate * amount spent on doing such tasks = project money spent Now how has the project money spent impacted the overall project costs, compared with the solution that everyone else is using, including the training costs for the rest of team, setting up a new build infrastructure, possible extra tooling support, salary rates for new hires? Somehow I feel many coders would profit to learn a bit more about business and project management.
      - Dylan16807 9y ago
        > No it doesn't mean a business impact at all, unless it is proven by accounting. You're not understanding me. I'm saying that if the work would have this good business impact with the original language, then doing the same thing with better productivity (with the same worker) is better. I'm not saying that improved productivity is guaranteed to mean business impact. Just that it either makes a good thing better, or it takes a bad thing and doesn't make it worse. If someone is doing the wrong work, their rate of production is not to blame. > Now how has the project money spent impacted the overall project costs, compared with the solution that everyone else is using, including the training costs for the rest of team, setting up a new build infrastructure, possible extra tooling support, salary rates for new hires? Other than 'salary rate', all of that falls under productivity. If all those costs are going up enough to drop productivity, then the entire premise goes out the window! The premise was secretly using a different language to increase productivity. Secretly using a different language to decrease productivity is so obviously a bad idea that it's not worth discussing.
thinbeige 9y ago
Great quote and I had to smirk when reading this. It happens all the time. I remember a time when hiring RoR guys. Even the codebase was already in RoR, every new RoR dev said 'OMG we have to rewrite the entire app, the codebase is a mess'.
- bartread 9y ago
  It's true, and I had to smile at that too, although nowadays I tend to take the "it's all terrible, we have to rewrite everything" attitude as either venting frustration (which is fine unless it becomes disruptive to forward progress) or a sign of professional immaturity (which may or may not be a problem, depending on context).
- bogomipz 9y ago
  Sorry, what is RoR?
  - ec109685 9y ago
    Ruby On Rails.
oelmekki 9y ago
Probably common, but they seem to have asked for it. 3 years ago, they published a presentation on slideshare [1] where they explained they were migrating from a monolith to microservices. That could make sense for them, given their size, but they explained as well that "rails is for pet blogs" (in the content of the presentation) and that they will take the opportunity to use many different languages. As I mentioned in comments back then, this was due to cause problems (although, I did not imagine it would go as far as people rewriting others apps). [1] https://www.slideshare.net/pcalcado/from-a-monolithic-ruby-on-rails-app-to-the-jvm https://www.slideshare.net/pcalcado/from-a-monolithic-ruby-o...
- jameskegel 9y ago
  I think it is more of a management issue; had management stayed on top of the productivity of their workers this wouldn't have happened. A good project manager would have grilled someone over why they felt the need to rewrite someone else's code on the company dime.
tnolet 9y ago
I've literally experienced this exact gut reaction two times in the last couple of months at two different companies. Code that is working fine, might need a bug fix here and there, is deemed worthless and should be rewritten. These we're tiny dev team: 3, 4 people max, so it happens everywhere I guess.
- keypusher 9y ago
  It does not happen everywhere. It happens in companies lacking sufficient years of experience building software, without good management. It's so common as to be almost universal in engineers with less than 5 years of experience to encounter some important piece of software that they think is ugly and poorly written and embark on a massive rewrite that they think will fix all the problems.

by xfer 9y ago

Mikushi 9y ago

Happens everywhere. In corp I've seen engineers go behind their manager's back to write something in their favourite language knowing it would've been rejected if discussion had happen beforehand.

reustle 9y ago
That sounds like a reasonable reason to fire someone
- WJW 9y ago
  That depends on how well it works. If it blows up and costs the company a million bucks you get fired, if it works extremely well then you are a maverick genius. "Ask for forgiveness, not permission", etc. Not saying that the extent to which it was apparently done at soundcloud should be acceptable though.
  - sgt101 9y ago
    The extent indicates anarchy which indicates poor leadership. The issue must have been with the management culture - flat hierarchies don't mean free for alls!
- sgt101 9y ago
  It depends on the outcome of the discussion - which depends on your capability as a manager. Sometimes this behavior is because the manager is an arse who can't run a reasonable process of team decision making, and the covert development is a reasonable appeal from someone who is disenfranchised in the decision making process and is making a very valuable point. The employee so doing is highly engaged and valuable and firing them is an act of self harm. In other cases this is an act of aggression by an unreasonable and arrogant individual who doesn't care about the team or the company and is simply doing what they want. You have to judge - call it wrong (either way) and you have a problem that will cost you dearly. But be aware there are two sides to this coin and you might be the one that needs to learn. My questions are always : is this part of a pattern (conflict, poor performance, bad behaviour?); why don't I want to sit with this person for 2 hours with a coffee and understand whats going on?; why didn't the coffee heart to heart work out?
elmar 9y ago
I think most of google sucesses outside search were done like that without the CEO having knowledge.
- dzhiurgis 9y ago
  I was about to say the same, but it’s not exactly the same. You are free to build anything, but using existing stack. Not pickup new stack and rewrite something that’s not even broken. That said, probably more often than not, there’s an actual value in it.
  - elmar 9y ago
    I think reality is more serendipitous, ny view is that if you have hardworking creativy people working on side projects sometimes magic happens. For example: Android was a completely diferent tech stack from google.
    - din-9 9y ago
      Android was bought in though.
      - elmar 9y ago
        I heard in a lecture of Blitzscaling with Eric Schmidt that google founders got the Google Chrome and Android projects running inside google without him knowing the real breath and intentions of the projects. https://www.youtube.com/watch?v=hcRxFRgNpns https://www.youtube.com/watch?v=hcRxFRgNpns
        sgroppino 9y ago
        The main difference could be that google has loads of cash to burn trying things out. I don't know their history 100% but suspect they were pretty strict with standards when they were a small start up.
- tanilama 9y ago
pjmlp 9y ago
And then they go and write a blog entry about how much productive they are now, instead of what was the actual business impact if any, to the company customers or revenue.
- bartread 9y ago
  ^^^This. And too often little consideration is given to impact further down the line. E.g., does this tie up your development teams in future doing non-value-adding work to fix breaking changes? What effect does this have on ongoing support costs? How easy is this skillset to hire for? How does this fit in with our roadmap? But it doesn't matter because I've bolstered my CV and by the time those things become really painful I'll be long gone. </cynicism>
- Dylan16807 9y ago
  I don't follow. If they are coding the right things, then a real increase in productivity means better business impact. If they are coding the wrong things, then language doesn't matter. How can a programming language choice hurt the business through some mechanism other than productivity? You could say that such a behavior is "indicative of poor choices" but that's begging the question.
  - pjmlp 9y ago
    No it doesn't mean a business impact at all, unless it is proven by accounting. Programmer hourly rate * amount spent on doing such tasks = project money spent Now how has the project money spent impacted the overall project costs, compared with the solution that everyone else is using, including the training costs for the rest of team, setting up a new build infrastructure, possible extra tooling support, salary rates for new hires? Somehow I feel many coders would profit to learn a bit more about business and project management.
    - Dylan16807 9y ago
      > No it doesn't mean a business impact at all, unless it is proven by accounting. You're not understanding me. I'm saying that if the work would have this good business impact with the original language, then doing the same thing with better productivity (with the same worker) is better. I'm not saying that improved productivity is guaranteed to mean business impact. Just that it either makes a good thing better, or it takes a bad thing and doesn't make it worse. If someone is doing the wrong work, their rate of production is not to blame. > Now how has the project money spent impacted the overall project costs, compared with the solution that everyone else is using, including the training costs for the rest of team, setting up a new build infrastructure, possible extra tooling support, salary rates for new hires? Other than 'salary rate', all of that falls under productivity. If all those costs are going up enough to drop productivity, then the entire premise goes out the window! The premise was secretly using a different language to increase productivity. Secretly using a different language to decrease productivity is so obviously a bad idea that it's not worth discussing.

thinbeige 9y ago

Great quote and I had to smirk when reading this. It happens all the time. I remember a time when hiring RoR guys. Even the codebase was already in RoR, every new RoR dev said 'OMG we have to rewrite the entire app, the codebase is a mess'.

bartread 9y ago
It's true, and I had to smile at that too, although nowadays I tend to take the "it's all terrible, we have to rewrite everything" attitude as either venting frustration (which is fine unless it becomes disruptive to forward progress) or a sign of professional immaturity (which may or may not be a problem, depending on context).
bogomipz 9y ago
Sorry, what is RoR?
- ec109685 9y ago
  Ruby On Rails.

oelmekki 9y ago

Probably common, but they seem to have asked for it. 3 years ago, they published a presentation on slideshare [1] where they explained they were migrating from a monolith to microservices. That could make sense for them, given their size, but they explained as well that "rails is for pet blogs" (in the content of the presentation) and that they will take the opportunity to use many different languages. As I mentioned in comments back then, this was due to cause problems (although, I did not imagine it would go as far as people rewriting others apps). [1] https://www.slideshare.net/pcalcado/from-a-monolithic-ruby-on-rails-app-to-the-jvm https://www.slideshare.net/pcalcado/from-a-monolithic-ruby-o...

jameskegel 9y ago
I think it is more of a management issue; had management stayed on top of the productivity of their workers this wouldn't have happened. A good project manager would have grilled someone over why they felt the need to rewrite someone else's code on the company dime.

tnolet 9y ago

I've literally experienced this exact gut reaction two times in the last couple of months at two different companies. Code that is working fine, might need a bug fix here and there, is deemed worthless and should be rewritten. These we're tiny dev team: 3, 4 people max, so it happens everywhere I guess.

keypusher 9y ago
It does not happen everywhere. It happens in companies lacking sufficient years of experience building software, without good management. It's so common as to be almost universal in engineers with less than 5 years of experience to encounter some important piece of software that they think is ugly and poorly written and embark on a massive rewrite that they think will fix all the problems.