CRYPTOCHAOS

At Sprint.ly we’re big fans of shipping. So much so that we militantly remove anything that stands in our way of shipping, including process.

“You can’t ship process.” – Ethan Kaplan, VP of Product at Live Nation

This pattern is common to all great programmers I know: they're not experts in something as much as experts in becoming experts in something.

The best programming advice I ever got was to spend my entire career becoming educable. And I suggest you do the same.

Couldn't resist...

Moore characterizes simplicity as a force that must be applied instead of a passive goal. And he's right – all too often, I see developers failing to make the hard choices necessary to keep their applications simple. It's easier to just say yes to everything.

I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.

How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design) have resulted from that one small shortcut about 40 years ago?

Keep that in mind next time you want to cut a corner in your code.

As well considered Unix always seemed to be, the notion that hidden files were an unintended consequence of a "quick hack" is amusing...

Slowgrammers are like poison to a team. Just like that old saying “One bad apple can spoil the whole bunch”, One person within a team can bring the team down to their level. The team can sometimes only go as fast as their slowest player.

via .NET Rocks!

• "My point of view is that legacy code is just code without tests."
• "What's important is to try to imagine something that is just a bit better than what you have currently. If you can target those things, then over time you will really start to make a difference in the code base."
• [in order to reduce fear of a legacy codebase perform a scratch refactoring...] "Check out the code with no intent of checking it back in. Refactor different sections... enough to get a feel for the code base, to get a handle on it..."
• "Functional languages get us away from some of the issues that have become so problematic in testing... Functional programming reduces the number of side effects of code..."
• "C# is getting too big. Every time you turn around there's been something added to the language. I'd hate to see it end up like C++."
• [regarding the new raft of languages] It's a bit like the tower of babel. For so long we had a mono culture in the industry around java and visual basic. Now it's at the point where everyone and their brother is designing a new language."
• [Regarding OO languages hitting a wall] "I think there is something to that, but I also think it has to do more with the type systems."
• "There are two basic themes of type safety... Type inference and Laziness, create data structures and apply limitations after the fact. I recommend that people learn Haskell. It really throws your mind in strange directions."
• [Regarding OO programs becoming legacy...] "It seems to be the fate of everything... Progress happens."
• "The history of the next 30 years will be about mining the last 30 years"
• "The thing about learning Haskel... it's great... You just need to learn to think like a martian!"
• "When you're choosing the right tests for something you have to think about it very deeply. you have to understand exactly how it operates... as you go through that process you'll arrive at higher quality without necessarily putting the bugs in there in the first place. So TDD and unit testing in general gives us quality, not through just test failures, but by forcing us to think through our code deeper than we would otherwise."
• [Regarding Agile] "The only thing that gets me is that there seems to be a moratorium on design in the industry over the past 10 years. There was a time when peopled talked about the intricacies of object oriented design... Once you go ahead and say 'Design is going to emerge' people say 'oh well then, we don't have to talk about that'"
• [Regarding the question: has architecture been forgotten"] "I think to a degree... there are some not nice things that have happened with the nominal title of architect over the past 20 years. But architecture expertise is definitely necessary in many application domains but they have to have a real view into the code."
• "Architecture knowledge has to be in the team... It's a very communicative role."
• "The import thing is continuity of knowledge in the team... When you have that, everything works out well... When you don't, everything is a fishing expedition when you need to make changes.
• "Documentation is important but you don't want to get into the situation where everything is exquisitely detailed and has to be changed every time you change the code. It gets crazy."
• "If you see code that is crazy and odd and you understand Conway's law, it really says something about the team that produced it. If you need to produce code in a team effort, than that team needs to get along together in order to produce good code. Otherwise, they are just sabotaging each other... even if only subtly."
• Emergent design can work very well, but in large organizations with a large codebase you have teams that do a little work on some code and move on, a little work on other code and move on. With agile, the original goal was to have collective code ownership. In large organizations there is no ownership so you have an odd tragedy of the commons. In large organizations, there needs to be a notion of ownership and if you don't, you shouldn't be surprised with what you get."