3 ms·

I guess people make projects like this to show off on their CV, and they’re worried that bad code could have the opposite effect. That said, in hiring, I don’t

I guess people make projects like this to show off on their CV, and they’re worried that bad code could have the opposite effect. That said, in hiring, I don’t mind seeing bad code - it gives us a talking point about the constraints involved, and how you’d improve it.

berkes 5y ago
I'd much rather hire someone who shows how to manage a mess, than someone who tries to avoid that mess. Mess in code is inevitable. Taking on technical debt is fine, knowingly leaving certain parts messy is fine too. Provided you do so knowingly, and manageable. So, indeed: I very much prefer to see someone who has horrible code but can explain why it wasn't a problem there, or how they refactored out of it into a beauty, than someone who has one "initial commit" that is that beauty immediately. Edit: I've worked in places where there was a mess-paralysis. An in-grained fear for breaking stuff (but not the prowess to solve that with better CI, tests etc). Where we could not react to market or customer demands, where all progress was halted by that fear to have to go into "The Mess" and break stuff, or introduce New Mess.
- dgb23 5y ago
  I tend to overthink and hyperreflect when it comes to organisation and structure. Most of the time this doesn’t really help. One of my goals in the last year or so was to reduce that. A very simple but effective thing I started doing is writing „cleanup“ comments. Duplication, ad-hoc coupling and such. In the comments I sometimes decribe how one could go about it, so I remember later what the issue might be. There are several benefits to this. For one, prioritizing what matters in the moment. Letting things unfold for real, so the right structure becomes more obvious later. Also it sometimes sparks little discussions that are useful and reveal a pragmatic way forward.
  - berkes 5y ago
    And a third benefit: leave refactoring to the time when you have enough information to refactor. As c2 wiki has it[1] > * The first time you do something, you just do it. > * The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway.[...] > * The third time you do something similar, you refactor. E.g. I've seen a lot of Incidental Duplication being refactored out, leaving the code apparently cleaner, but in practice, really much worse. [1] http://wiki.c2.com/?ThreeStrikesAndYouRefactor http://wiki.c2.com/?ThreeStrikesAndYouRefactor
    - blowski 5y ago
      My theory as to why this happens. 1. You write some code. 2. You write a duplicate of #1. 3. You write another duplicate of #1, so you should refactor. But the PM doesn't understand why you're changing the code you made in #1 and #2 as part of ticket #3. So the jaded devs are certain the duplication will occur, but believe their choice is either to pre-emptively fix the duplication at #1, or never to fix it at all.
      - berkes 5y ago
        > But the PM doesn't understand why you're changing the code you made If that is the case, the PM does not understand red-green-refactor, always-refactoring, or even just plain refactoring. I'd say the PM doesn't even understand the idea of technical debt, in that case. The problem is certainly the PM's disconnect to how to keep a codebase (and their team) sane in the most common programming practices. And not the refactoring itself.
        blowski 5y ago
        I agree with that assessment on the surface. But it's a sign of a generally unhealthy team, not just a poor PM (although the poor PM might be the root cause).
eatonphil 5y ago
I have a ton of public code that I link to in my resume and not since my first job out of school has any interviewer looked at it and asked me questions about it. Even the people who want you to do a coding project would not take my existing code over rewriting from scratch for their purposes. (And yeah on the one hand that's fair, but also I did not go through with those interviews.)

berkes 5y ago

I'd much rather hire someone who shows how to manage a mess, than someone who tries to avoid that mess. Mess in code is inevitable. Taking on technical debt is fine, knowingly leaving certain parts messy is fine too. Provided you do so knowingly, and manageable. So, indeed: I very much prefer to see someone who has horrible code but can explain why it wasn't a problem there, or how they refactored out of it into a beauty, than someone who has one "initial commit" that is that beauty immediately. Edit: I've worked in places where there was a mess-paralysis. An in-grained fear for breaking stuff (but not the prowess to solve that with better CI, tests etc). Where we could not react to market or customer demands, where all progress was halted by that fear to have to go into "The Mess" and break stuff, or introduce New Mess.

dgb23 5y ago
I tend to overthink and hyperreflect when it comes to organisation and structure. Most of the time this doesn’t really help. One of my goals in the last year or so was to reduce that. A very simple but effective thing I started doing is writing „cleanup“ comments. Duplication, ad-hoc coupling and such. In the comments I sometimes decribe how one could go about it, so I remember later what the issue might be. There are several benefits to this. For one, prioritizing what matters in the moment. Letting things unfold for real, so the right structure becomes more obvious later. Also it sometimes sparks little discussions that are useful and reveal a pragmatic way forward.
- berkes 5y ago
  And a third benefit: leave refactoring to the time when you have enough information to refactor. As c2 wiki has it[1] > * The first time you do something, you just do it. > * The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway.[...] > * The third time you do something similar, you refactor. E.g. I've seen a lot of Incidental Duplication being refactored out, leaving the code apparently cleaner, but in practice, really much worse. [1] http://wiki.c2.com/?ThreeStrikesAndYouRefactor http://wiki.c2.com/?ThreeStrikesAndYouRefactor
  - blowski 5y ago
    My theory as to why this happens. 1. You write some code. 2. You write a duplicate of #1. 3. You write another duplicate of #1, so you should refactor. But the PM doesn't understand why you're changing the code you made in #1 and #2 as part of ticket #3. So the jaded devs are certain the duplication will occur, but believe their choice is either to pre-emptively fix the duplication at #1, or never to fix it at all.
    - berkes 5y ago
      > But the PM doesn't understand why you're changing the code you made If that is the case, the PM does not understand red-green-refactor, always-refactoring, or even just plain refactoring. I'd say the PM doesn't even understand the idea of technical debt, in that case. The problem is certainly the PM's disconnect to how to keep a codebase (and their team) sane in the most common programming practices. And not the refactoring itself.
      - blowski 5y ago
        I agree with that assessment on the surface. But it's a sign of a generally unhealthy team, not just a poor PM (although the poor PM might be the root cause).

eatonphil 5y ago

I have a ton of public code that I link to in my resume and not since my first job out of school has any interviewer looked at it and asked me questions about it. Even the people who want you to do a coding project would not take my existing code over rewriting from scratch for their purposes. (And yeah on the one hand that's fair, but also I did not go through with those interviews.)