Month: October 2018

I have been a programmer for about 5 years at this point and as part of that I have read 10,000s of lines of documentation, lots of books and solved plenty of problems. I have also read tons of content trying to find solutions to the problems in my life. Add in a lot of time reflecting on what I could do to resolve those same problems and you end up with a massive amount of time spent trying to figure things out and a much smaller amount of time spent doing things to solve problems. 

As I have gone through more and more information, I have found that the solutions to my problems have gotten simpler and simpler. Lots of problems overlap and once you figure out one, the others get easier. Much like if you can solve one NP complete problem you can solve all of them. Because the solution to ‘solve a problem in your life’ is pretty basic. 

I see a lot of ‘older’ guys who give advice, aka gurus, who get frustrated, because younger guys keep asking complicated questions on the same topics, over and over. On the subreddit /r/cscareerquestions, every semester we see the same questions about applying for programming jobs. If you are having trouble finding a job after graduation the answer is the same for just about everyone. 

“I have applied to x number of jobs and no one gets back to me, am I cut out for programming?” — common question

Rote Answer:

1. Can you solve FizzBuzz or Hacker rank easy questions in 30min after practicing? 
2. Get help with your resume, either on reddit or pay a professional.
3. Apply for more jobs, don’t come back until you have applied for 100 more.

Your situation is unique in all sorts of ways, but if you are a college senior applying for programming jobs your unique factors probably do not matter compared to the three points above. 

There is only so much information that is relevant and if it takes a decade to go through the important bits, at some point you have to stop reading.

On my last project as an architect, I found myself drifting into an architecture strategy of keeping everything as simple as possible. In choosing a database I would look at our projected usage, multiply the number by ten and evaluate which database would be the simplest given our requirements. Given the size of an external library is it better to import it as a black box or to write the functionality as a single file module? The project being in Go made a few of the choices easier because Go does not offer many higher level features. Instead of worrying about class hierarchies you just write the functionality you need. 

Keeping it stupid means choosing an architecture that anyone would understand at first look. Other people should always assume that they could have come up with the architecture when they read it. There shouldn’t be any surprises or ‘cool’ technology choices. There is a blog post out there about how a startup or software team can afford to pick one risky technology before going bust. In KIS architecture you never pick a risky technology. 

In the 2018 Software Engineer’s toolbox are dozens of technologies that are both proven and incredibly powerful. We have access to many of the common tools as managed services in the cloud making things even easier. Save yourself the trouble, keep your architecture stupid until its proven that it needs to be more complicated.