111–120 of 286 posts
Nice post, organization definitely is one of the most overlooked aspects of programming. It takes a lot of experience and thinking to be able to organize properly. It's really what separates the beginner programmers and the experienced ones.
- Incomplete, conflicting and misunderstood requirements.
- Lots of "We never thought we would need to do X".
- Poor team communication.
- Mistrust, frequently well earned.
- Harmony valued over truth.
Once these were winnowed away, the problems rarely overwhelmed the technical teams. This isn't to diminish the importance of technical skills. Rather - when everything else is f*cked up, you can't blame the technology or expect a 10xer to pull you out of it.
Earlier quoted context omitted.
How'd you do it if the keyboard wasn't working?
Our main product was developed on a keyboard that was missing a "w". It's not a big deal, though - you can use a for(;;) loop instead of a while loop without hurting performance. And it's easy to just avoid "w" words in the view templates by being clever with word choice. Of course, that's not true at all. But giving someone a defective-but-not-entirely-broken tool can be a clever way of seeing how they work around p…
the number one most important skill is how to keep a tangle of features from collapsing under the weight of its own complexity Agreed. very rarely is there some tricky data structure or algorithm that casts a looming shadow over everything else Agreed, BUT... In order to organize, sooner or later, you will have to get clever (with tricky data structures or algorithms). How I have always built something big and/or com…
From [1]: > Nobody is really smart enough to program computers. Fully understanding an average program requires an almost limitless capacity to absorb details and an equal capacity to comprehend them all at the same time. The way you focus your intelligence is more important than how much intelligence you have. > At the 1972 Turing Award lecture, Edsger Dijkstra delivered a paper titled "The Humble Programmer." He ar…
I try to imagine that 6 months from now I'll have a critical bug in whatever I'm writing and so I write it for that.
Apropos of nothing, I'd love an editor that could completely hide (not collapse) comments, as when something I write them I don't need them so hiding them would be great but showing them but been able to toggle them on later would be awesome.
Earlier quoted context omitted.
But design patterns are horrible at organizing code. They have a much higher chance of introducing unneeded complexity. It should be no surprise that almost every single design pattern can be replaced with a simple lambda in languages supporting them.
Design patterns are excellent at creating the illusion of organisation. I recently had to modify someone else's Mac app. On the surface it looked like a textbook example of successful use of design patterns. Everything was highly modular, functions were simple, there was clear separation of concerns, controllers and views were distinct, and so on. Problem was, the key features were still baked in and hard to modify.…
Features are by definition almost always cross-cutting concerns in that they touch half the systems that makes up the application.
Even if your systems are pure isolated islands properly decoupled from each other, they can still be tangled back into a spaghetti mess when wiring it all together.
Furthermore, design patterns define data structures rather than data flow, even the behavioral ones, making them horrible at organizing the application's features.
This is incredibly true. I once turned 60kLoC of classic ASP in VBScript into about 20kLoC of python/django including templates. And added a bunch of features that would have been impossible on the old code-base. It turned the job from hellish (features were impossible to add) to very nearly boring (there wasn't much to do anymore). So with this newfound freedom I built some machines to automate the data entry and on…
> Sadly there's (seemingly) no way to interview people for this ability I think there is. Show the candidate some bad code. Not WTF code, but something you wouldn't be proud of but is realistic. Bonus points if you're comfortable enough to pull this out of your own production system. Ask the candidate about adding some functionality, but be clear that cleanup and refactoring changes are fine (even encouraged). The co…
Being able to search for and manipulate symbols at the AST level goes a long way towards eliminating any resistance to refactoring.
- 10% of the LOC as previously
- Code significantly more understandable
- Jr. developer on the team suddenly became a rockstar b/c he could understand what was going on.
Earlier quoted context omitted.
How'd you do it if the keyboard wasn't working?
Our main product was developed on a keyboard that was missing a "w". It's not a big deal, though - you can use a for(;;) loop instead of a while loop without hurting performance. And it's easy to just avoid "w" words in the view templates by being clever with word choice. Of course, that's not true at all. But giving someone a defective-but-not-entirely-broken tool can be a clever way of seeing how they work around p…
(And then make a preprocessor run where \/\/ is replaced with a w)