Solution driven design

Really nice and insightful post. Two thoughts came to mind when I was reading:

1) The temptation to write code because it will feel good to write it - maybe it's a really clever solution, or maybe you've been itching to try some new framework or library - is really, really hard to resist. But it's super valuable to resist it.

I find it's best to think of my job as a developer not as being to write code per se but instead to solve problems related to computation as efficiently as possible. Finding a third-party SaaS product that does what we need is almost always much better than writing a new microservice from scratch. Jeff Atwood has written some really insightful stuff about this [0].

I'm inclined to think that actually writing new code will only become a smaller and smaller portion of software engineering going forward over the next, say, five to twenty years. Between the profusion of open-source tools and third-party services developers seem to be spending more and more time stitching things together. The job seems to increasingly be about evaluating and choosing between various off-the-shelf components rather than implementing algorithms from scratch.

2) On an entirely different note:

> Never make a move JUST because it is your turn to play.

This quote made me think of a common conversational phenomenon. People will tend to talk when they feel like someone should be talking, whether or not they really have something they want to say. For example, in an interview, if you don't respond when it would naturally be your turn to respond the other person will likely keep talking after a short pause, and likely slightly awkwardly. It's kind of funny and be kind of mean, but it can be a powerful way to get a person to say more than they initially thought they should about something.

[0] For example: http://blog.codinghorror.com/the-best-code-is-no-code-at-all...