4 ms·

> it was absurd to expect anyone to want this as their full time job for even a month or two That gave me a true 'kids these days' moment... In my day within

by Jare 6y ago

> it was absurd to expect anyone to want this as their full time job for even a month or two That gave me a true 'kids these days' moment... In my day within a spanish bank, as a team of 4 interns, we spent over 6 months reviewing/documenting an entire proprietary platform C codebase (full of gotos, endian-dependent hacks, post-compile patches and every horrible thing you could imagine), and then with a larger (~3x) team about 12 months cleaning, porting and expanding that codebase to a clean platform (if you can call SCO Unix 'clean'). What sort of dynamics prevent a product startup like Dropbox build an engineering team that includes the capability to do such a task?

bcrosby95 6y ago
Because startups tend to use how much you enjoy coding as a proxy for how good of a coder you are. So if you purposefully hire a bunch of people because they like coding, it's going to cause a shitload of problems once you unleash an "unfun" job like this on them for such a long period of time.
- whynotminot 6y ago
  Wait what? So you should hire coders who don't like coding to do coding?
  - nojito 6y ago
    People who "like" coding tend to prefer hot new tech as a way of experimentation. They often ignore the actual business problem that needs to be solved, because it can be solved using "boring" technology.
    - koz_ 6y ago
      The thing is boring tech is often really just painful tech, where pain manifests in lots of different ways (error-prone repetition, painful manual testing, hard to read spaghetti code, etc). Programmers who are too insensitive to pain will continue to generate pain for themselves and others.
    - hombre_fatal 6y ago
      Seems like an invention on your part. I also sense some condescension towards this alleged group of people that you insist exists. The reality is that people who like coding and thus trying new things are limited by the stack their job uses. Simple as that. I don't really understand your hypothetical scenario where this alleged person is working on the new FooQux framework instead of getting work done. That's just someone who isn't doing their job. That they enjoying writing code seems irrelevant. Like trying to say people who like water skiing are awful employees because they're on the lake all day. We need a word for this kind of HN trope. Condescension roleplaying?
      - perl4ever 6y ago
        My last phone screen, I emphasized that I like solving business problems, rather than tech for its own sake. They decided I "wasn't technical enough"...without asking me a single technical question. That's the culture clash people frequently reference, and it's very real. If you don't perceive it, it's because you're swimming in it. And I emphasize that the attitude, that the only good coders have tunnel vision and just want to play obsessively with tech, but only the cool stuff, goes far, far beyond the stereotypical SF startup environment or whatever. Because a large number of companies have a vague idea that to be cool, they should imitate what the trendy companies do, so even if you question the stereotype, the stereotype influences reality.
  - mwcampbell 6y ago
    Maybe it's more about hiring people with a strong work ethic, who will do whatever needs doing, not just what's fun. Note: I don't think I'm really one of those people.
  - Tade0 6y ago
    The most productive developer I currently have the privilege to work with isn't visibly passionate about the thing. She got back into this career after being a project owner for a few years and now just pushes forward like an icebreaker. And the code isn't even "pretty" - it's just well-tested and is working as intended. Makes one question some assumptions about what makes a good developer.
- Jare 6y ago
  Consider that I joined the bank as an intern and college student, but I had been programming for 10 years (almost 100% assembly) including two commercial video games published in my teens. And there was another like me in the team. We loved coding dearly, and 30 years later I still do (the other one pivoted into law, ah well). But work's work and must get done, right?
- austincheney 6y ago
  As a JavaScript developer this is limited only to everywhere. As for myself I like coding, but what I really mean is I like writing original software to solve automation problems, which clearly not the same definition some of my prior colleagues have used.
iliekcomputers 6y ago
I would assume most engineers would like to spend time building stuff instead of migrating already built stuff to a different but kinda similar language. I don't think it's unreasonable to not want to do a CoffeeScript to TypeScript migration full time for an entire year. It's basically the equivalent of creating a "tech-debt" team and giving them only tasks which pay down tech debt. Sure, there are situations where tech debt needs to be paid down and you could make an entire team do it for an year, but the engineers will probably not _like_ being on the team.
dgoldstein0 6y ago
I didn't say people wouldn't do it. Some people actually did! the whole Maestro team, for most of Q2 2017, for instance. Part of my point though is that converting coffeescript to typescript was very boring, mostly mechanical work (which is more obvious in hindsight, since we actually automated most of it). Sure, you could make the code better while you are there, but that actually was likely to add bugs, which could significantly delay such conversions, or lead you to chasing around the codebase to figure out how to get typechecking to work with your attempt at better types. What you are describing - going through an old codebase and figuring out how to fix it - sounds a lot more interesting! though definitely there are plenty of people who wouldn't want that job either. But really the biggest blocker to executing on the manual conversion strategy was management. They already had other commitments for their teams, and spending a few thousand hours converting coffeescript to typescript wasn't as high of a priority for most of them, than the things their teams were actually working on. This partly comes down to our incentive structure - doing work for other teams, especially in a migration like this, can often feel like a chore, and is often not really rewarded with anything. But prioritization for a large project like this also takes a lot of input from upper management, and they didn't want to sacrifice other priorities to keep the original manual conversion plan on track.
- Jare 6y ago
  I guess part of what you are saying is, that getting that task done was not so important for Dropbox in the grand scheme of things. In the case I described, it was life and death for the entire organisation (proprietary hardware platform was EOL'd, so cero possibility of growth), and the managers that led it (and trusted 4 interns to do the ground work!) got rewarded handsomely AFAIK. Thanks for a great writeup and clarifications!
fuzetsu 6y ago
Someone being sympathetic about boring code migration work gave you a 'kids these days' moment...? My take away from that was more that if you can avoid the manual labor do so, which seems fair enough to me.
- Jare 6y ago
  The writer of the piece was not the "kid" in my comment. People who, by my understanding, would allow the work to remain not done because it was boring to do it, are. There's more clarification about the comment in the replies.

by Jare 6y ago

bcrosby95 6y ago

Because startups tend to use how much you enjoy coding as a proxy for how good of a coder you are. So if you purposefully hire a bunch of people because they like coding, it's going to cause a shitload of problems once you unleash an "unfun" job like this on them for such a long period of time.

whynotminot 6y ago
Wait what? So you should hire coders who don't like coding to do coding?
- nojito 6y ago
  People who "like" coding tend to prefer hot new tech as a way of experimentation. They often ignore the actual business problem that needs to be solved, because it can be solved using "boring" technology.
  - koz_ 6y ago
    The thing is boring tech is often really just painful tech, where pain manifests in lots of different ways (error-prone repetition, painful manual testing, hard to read spaghetti code, etc). Programmers who are too insensitive to pain will continue to generate pain for themselves and others.
  - hombre_fatal 6y ago
    Seems like an invention on your part. I also sense some condescension towards this alleged group of people that you insist exists. The reality is that people who like coding and thus trying new things are limited by the stack their job uses. Simple as that. I don't really understand your hypothetical scenario where this alleged person is working on the new FooQux framework instead of getting work done. That's just someone who isn't doing their job. That they enjoying writing code seems irrelevant. Like trying to say people who like water skiing are awful employees because they're on the lake all day. We need a word for this kind of HN trope. Condescension roleplaying?
    - perl4ever 6y ago
      My last phone screen, I emphasized that I like solving business problems, rather than tech for its own sake. They decided I "wasn't technical enough"...without asking me a single technical question. That's the culture clash people frequently reference, and it's very real. If you don't perceive it, it's because you're swimming in it. And I emphasize that the attitude, that the only good coders have tunnel vision and just want to play obsessively with tech, but only the cool stuff, goes far, far beyond the stereotypical SF startup environment or whatever. Because a large number of companies have a vague idea that to be cool, they should imitate what the trendy companies do, so even if you question the stereotype, the stereotype influences reality.
- mwcampbell 6y ago
  Maybe it's more about hiring people with a strong work ethic, who will do whatever needs doing, not just what's fun. Note: I don't think I'm really one of those people.
- Tade0 6y ago
  The most productive developer I currently have the privilege to work with isn't visibly passionate about the thing. She got back into this career after being a project owner for a few years and now just pushes forward like an icebreaker. And the code isn't even "pretty" - it's just well-tested and is working as intended. Makes one question some assumptions about what makes a good developer.
Jare 6y ago
Consider that I joined the bank as an intern and college student, but I had been programming for 10 years (almost 100% assembly) including two commercial video games published in my teens. And there was another like me in the team. We loved coding dearly, and 30 years later I still do (the other one pivoted into law, ah well). But work's work and must get done, right?
austincheney 6y ago
As a JavaScript developer this is limited only to everywhere. As for myself I like coding, but what I really mean is I like writing original software to solve automation problems, which clearly not the same definition some of my prior colleagues have used.

iliekcomputers 6y ago

I would assume most engineers would like to spend time building stuff instead of migrating already built stuff to a different but kinda similar language. I don't think it's unreasonable to not want to do a CoffeeScript to TypeScript migration full time for an entire year. It's basically the equivalent of creating a "tech-debt" team and giving them only tasks which pay down tech debt. Sure, there are situations where tech debt needs to be paid down and you could make an entire team do it for an year, but the engineers will probably not _like_ being on the team.

dgoldstein0 6y ago

I didn't say people wouldn't do it. Some people actually did! the whole Maestro team, for most of Q2 2017, for instance. Part of my point though is that converting coffeescript to typescript was very boring, mostly mechanical work (which is more obvious in hindsight, since we actually automated most of it). Sure, you could make the code better while you are there, but that actually was likely to add bugs, which could significantly delay such conversions, or lead you to chasing around the codebase to figure out how to get typechecking to work with your attempt at better types. What you are describing - going through an old codebase and figuring out how to fix it - sounds a lot more interesting! though definitely there are plenty of people who wouldn't want that job either. But really the biggest blocker to executing on the manual conversion strategy was management. They already had other commitments for their teams, and spending a few thousand hours converting coffeescript to typescript wasn't as high of a priority for most of them, than the things their teams were actually working on. This partly comes down to our incentive structure - doing work for other teams, especially in a migration like this, can often feel like a chore, and is often not really rewarded with anything. But prioritization for a large project like this also takes a lot of input from upper management, and they didn't want to sacrifice other priorities to keep the original manual conversion plan on track.

Jare 6y ago
I guess part of what you are saying is, that getting that task done was not so important for Dropbox in the grand scheme of things. In the case I described, it was life and death for the entire organisation (proprietary hardware platform was EOL'd, so cero possibility of growth), and the managers that led it (and trusted 4 interns to do the ground work!) got rewarded handsomely AFAIK. Thanks for a great writeup and clarifications!

fuzetsu 6y ago

Someone being sympathetic about boring code migration work gave you a 'kids these days' moment...? My take away from that was more that if you can avoid the manual labor do so, which seems fair enough to me.

Jare 6y ago
The writer of the piece was not the "kid" in my comment. People who, by my understanding, would allow the work to remain not done because it was boring to do it, are. There's more clarification about the comment in the replies.