4 ms·

The guts or the discipline? Dynamic doesn't really cause problems in its own. Only abuse of it which can be said about most things. I guess there is an argume

by lugg 8y ago

The guts or the discipline? Dynamic doesn't really cause problems in its own. Only abuse of it which can be said about most things. I guess there is an argument that f forces you to have good habits but that comes at a pretty big cost if your team is half decent.

Someone1234 8y ago
"Just write good code" or "Just hire perfect programmers" the go to retort for any language weakness. I've been in this industry long enough to just roll my eyes every time I hear that now, it simply doesn't scale beyond one individual.
- lugg 8y ago
  Good thing I didn't say or imply either of those then. I said don't abuse language features. That is a far cry from writing perfect code. Non perfect code is expected early in a startup, I'm just saying don't confuse your non perfect code with a language failure. I'd also like to say if you've never seen "hire perfect developers" scale passed one you've been optimising for the wrong thing. I've seen a team go from technical debt hell and dread to a powerhouse team where everyone commits daily. It doesn't take much, and it doesn't take perfect developers, and it certainly doesn't have anything to do with the language. It had everything to do with honest and healthy code review. It had everything to do with people feeling comfortable enough to say, your solution is a hack, why are you taking this shortcut. That isn't write perfect code, or hire the right people. That is hire pretty much whoever will take the job. That is prioritising and optimising for quality. We still had a legacy code base, it still made us money, and it gave us the time opportunity to do things right, but you still need to take the time.
biesnecker 8y ago
My team might be half decent. So might the dozens of other teams working on the code base over years and years. Everyone will certainly have the best of intentions. But mistakes will certainly be made. Misunderstandings will occur. Note I said "now let's scale" -- it's pretty easy to rely on good practices and a steady hand when it's a dozen engineers in a room. When it's a thousand engineers in three timezones it's a fair bit harder. Edit: typo
- lugg 8y ago
  Well actually you said "let's move fast and then let's scale" as in you were implying there was some technical debt built up by moving fast. You can move slow, choosing a static language only imposes that on you, it doesn't fix the underlying problem (developers being lazy.)

by lugg 8y ago

Someone1234 8y ago

"Just write good code" or "Just hire perfect programmers" the go to retort for any language weakness. I've been in this industry long enough to just roll my eyes every time I hear that now, it simply doesn't scale beyond one individual.

lugg 8y ago
Good thing I didn't say or imply either of those then. I said don't abuse language features. That is a far cry from writing perfect code. Non perfect code is expected early in a startup, I'm just saying don't confuse your non perfect code with a language failure. I'd also like to say if you've never seen "hire perfect developers" scale passed one you've been optimising for the wrong thing. I've seen a team go from technical debt hell and dread to a powerhouse team where everyone commits daily. It doesn't take much, and it doesn't take perfect developers, and it certainly doesn't have anything to do with the language. It had everything to do with honest and healthy code review. It had everything to do with people feeling comfortable enough to say, your solution is a hack, why are you taking this shortcut. That isn't write perfect code, or hire the right people. That is hire pretty much whoever will take the job. That is prioritising and optimising for quality. We still had a legacy code base, it still made us money, and it gave us the time opportunity to do things right, but you still need to take the time.

biesnecker 8y ago

My team might be half decent. So might the dozens of other teams working on the code base over years and years. Everyone will certainly have the best of intentions. But mistakes will certainly be made. Misunderstandings will occur. Note I said "now let's scale" -- it's pretty easy to rely on good practices and a steady hand when it's a dozen engineers in a room. When it's a thousand engineers in three timezones it's a fair bit harder. Edit: typo

lugg 8y ago
Well actually you said "let's move fast and then let's scale" as in you were implying there was some technical debt built up by moving fast. You can move slow, choosing a static language only imposes that on you, it doesn't fix the underlying problem (developers being lazy.)