Comments by "Daniel Sandberg" (@ddanielsandberg) on "Is This Why You’re Bad At Programming?" video.

  1. Unfinished code (meaning new features or a replacement feature) should be hidden behind some kind of config. Small refactorings and minor changes don't need flags but should be covered by automated tests. Early in development we hide it behind a compile/packaging-time flag within our build scripts. Later on we convert it into a deployment-time flag (or maybe even some kind of dynamic plugin-like config) so we can have different behaviors in different environment and test with/without the new features. When the feature is in "open beta" we change the flag to a runtime/properties/preference/opt-in/something config. Whether this is only done in the UI or something deeper down in the system depends on the kind of change. Now, I really dislike the question "Let's say 100 people are implementing features and 10 people don't finish" because it implies everyone works alone and one single person having a bad week can make the entire thing fall down. Talk about bad leadership and development practices. Either the entire team fails or succeeds. If 90 persons are "done" and 10 aren't; what the hell did those other 90 people do? Sat around fiddling because they "did their part" and already gotten the gold star from the boss? They didn't help? *It's not the 10 people that got stuck fault some plan went bad, it's the other 90 people + the leadership that needs to get their heads straight.*
    2
  2. I think there is this idea that we programmers only get one chance to implement something. Everything is a one-off "task/project" and then we move on to the next thing. Nothing is ever perfect, learn to accept that and then do something about it. Committing unperfect code, unperfect design, janky solutions (that nevertheless works) is actually OK. What it requires is that people actually have to learn to refactor, redesign, and do continuous improvement all the time. It's never perfect, it's never done, so get into the mindset of always fixing and improving things that looks "off". It is a good idea for the team to have reoccurring reviews of the current state of the software and always improve issues as they are found. The second problem is that every programmer thinks to believe that programming is a solemn activity. That is wrong; it's a social activity. In a company setting I see FB/PR as a symptom of missing teamwork and/or bad organizational leadership. If every developer wants to work alone and only intermittently "communicate" and "integrate" using PRs and "do their own stuff" you don't have a team. Don't you talk? And yes, we love to use dumb excuses like "but I'm an introvert", etc which is just BS to avoid having to talk with other people and getting paid doing our hobby. (I'm an introvert and I love pair programming and co-located teams and problem solving with a bunch of people in the same room. I hate parties and "social crap".) Like Jesus fing Christ. We programmers need to get over ourselves.
    1