3 ms·

It's amazing what you can get accomplished with a team size of one. For me it boils down to being able to fit the entire codebase into your head, or at the ver

It's amazing what you can get accomplished with a team size of one. For me it boils down to being able to fit the entire codebase into your head, or at the very least have it all written in your own voice. Reading code and packing it into your brain is the hardest part of programming, so having it all written in your own familiar style makes it really easy to get back up to speed on any bit of the project, even if you haven't visited it in a while. Having even one other developer in there making changes can throw you out of speed-reading mode and make you stop and figure out what the other guy was thinking. That slows you down, and slowing down opens the door to distraction, which leads to bad things. It gets really good when you're working by yourself on a project for which you're providing the direction. That removes the last roadblock from productivity, the "boss requested change".

agentultra 16y ago
As long as you document your style, I totally agree. Nothing like it, if you're lucky enough to be blazing the trail. The problem is for engineers who come in after you've left for greener pastures. If you don't document your style, design decisions, and over-all development process you're leaving behind a legacy... of miserable programmers who will make up stories about how awful you must have been.
- zeemonkee 16y ago
  Document, comment appropriately and write tests. The engineer in question might be yourself, six months or a year later, and you will have completely forgotten what you were doing back then.
rue 16y ago
As with most things, being exposed to different influences tends to make you a better programmer. So does fairly routinely getting a grasp of a big or otherwise alien codebase. It might not work for everyone, of course, but it is probably beneficial for 90% of working programmers. So do not use this as an excuse to not try pairing (or working in larger teams, others' code etc.) with an open mind.
- flatline 16y ago
  I would agree that different influences make you a better programmer, but perhaps not in the way that you meant. Almost every code base I've worked on in industry has been - and I think that most of my co-workers would agree with me - a steaming pile of code that barely functions well enough to do the desired task and is a nightmare to maintain. I've seen this at small shops and big corporations alike. Most of the really nice stuff that I've seen has been from OSS projects and books, and occasionally some project that a lone developer hacked out from scratch with little oversight and few constraints. Dealing with the ugly stuff has given me a good feel for anti-patterns and things to avoid from the get-go, but it has not exactly been a positive influence.

agentultra 16y ago

As long as you document your style, I totally agree. Nothing like it, if you're lucky enough to be blazing the trail. The problem is for engineers who come in after you've left for greener pastures. If you don't document your style, design decisions, and over-all development process you're leaving behind a legacy... of miserable programmers who will make up stories about how awful you must have been.

zeemonkee 16y ago
Document, comment appropriately and write tests. The engineer in question might be yourself, six months or a year later, and you will have completely forgotten what you were doing back then.

rue 16y ago

As with most things, being exposed to different influences tends to make you a better programmer. So does fairly routinely getting a grasp of a big or otherwise alien codebase. It might not work for everyone, of course, but it is probably beneficial for 90% of working programmers. So do not use this as an excuse to not try pairing (or working in larger teams, others' code etc.) with an open mind.

flatline 16y ago
I would agree that different influences make you a better programmer, but perhaps not in the way that you meant. Almost every code base I've worked on in industry has been - and I think that most of my co-workers would agree with me - a steaming pile of code that barely functions well enough to do the desired task and is a nightmare to maintain. I've seen this at small shops and big corporations alike. Most of the really nice stuff that I've seen has been from OSS projects and books, and occasionally some project that a lone developer hacked out from scratch with little oversight and few constraints. Dealing with the ugly stuff has given me a good feel for anti-patterns and things to avoid from the get-go, but it has not exactly been a positive influence.