On Starting Simply


6 minute read


On Starting Simply | ifelse.io

tl;dr: I’m following up on my “Start Simply, Simply Start” from a bit ago with some more practical thoughts on starting simply. My hope is to also write on the second of these ideas, “On Simply Starting.”

Simplicity is a prerequisite for reliability

  • Edsger W. Djikstra

I wrote a short(ish) post a bit ago about starting and starting simply. It was a rather “in the moment” piece of writing, not one I’d spent a long time actually composing. It was, nonetheless, certainly one I’d spent a good deal of time ruminating on and experiencing. In fact, I’ve spent far too much time not starting and not starting simply, and so it was perhaps a long time in coming, both in its manifestation and formulation.

Blustery writing is too easy and too quick, however, and is often over before anything helpful has been said. So, I wanted to follow theoria with praxis and provide some more practical and pointed thoughts on starting simply.

Dramatis Personae

  • Learn principles, use tools
  • Do one thing well
  • Fundamentals matter
  • Learn paradigms, patterns, not frameworks
  • Build to learn, learn to build

##Learn Principles, Use Tools I suppose that starting simply is a challenge to those learning to program as well as experienced developers and teams. But I think it is an especially pertinent one for new developers and I have had them most in mind when writing this. Those just entering the software engineering field, either from a CS background or a non-CS one, will find themselves in an incredibly complex world of software development communities, tools, paradigms, &c. As such, they seem to gravitate towards what is easy instead of what is simple.

In my experience, the typical path taken for a newcomer, especially one from a non-CS background, looks something like this:

  1. Decide to be developer.
  2. Learn either by MOOC or bootcamp.
  3. Get job, presume competency
  4. Discover not nearly the case, learn new framework/general tool/buzzword
  5. Discover not nearly the case, learn new framework/general tool/buzzword
  6. Presume competency

and so it goes: presume competency, new framework, presume competency, …n

The trouble with this approach is that you’re continually learning to the lowest common denominator. Frameworks have their many benefits, but evolve with the general pace of development and innovation and exist to make things easy. And if you’re continually working towards ease, you’ll find yourself constrained by the limits of the tools you’ve learned.

learn principles, use tools

Invert that relation: learn principles (paradigms, patterns, &c.), use tools. If you’re only ever learning tools, they will set and be your limiting factor. By learning paradigms (functional, reactive, OOP, &c.) and patterns, you’ll be able to create and understand your tools and move freely without the burdens of an ease constraint.

T.S. Eliot was known to have asked:

“If you aren’t in over your head, how do you know how tall you are?” ― T.S. Eliot

Oftentimes, it seems to be the case that developers who are stuck in this dependency graph are generally either afraid of the difficulties of moving outside easy thinking or have placed low capacitive limitations on themselves. Try getting in over your head, find out how tall you are.

Now, my emphasis on fundamentals is not to suggest that everyone needs to be operating at the equivalent of a computer science PhD1. However, we would all be better served by abandoning the endless pursuit of ease and be better in our roles, junior to senior, frontend to backend.

Over time, if you keep striving after simplicity and depth rather than breadth, the general pace of innovation and perhaps job environments you work in will help add breadth to your skills. At times, it might even be advisable to purposefully add some breadth by exploring other paradigms and sub-disciplines. But by keeping your focus on learning the deeper, more general, and, admittedly, more difficult things, you’ll not only start but stay simple. You’ll weather sea-changes in the industry, be able to move between projects, change your focus, and more.

If you’re just starting out, what does this mean for you? Stick to learning something, hopefully a language, really, really well before you start to rely on the easy things. The general ordering of learning priorities should flow from more fundamental to less, from more low-level to high-level.

##Start, Stay Simple To that end, here’s a few points on how to start and stay simple. If you’re not just starting out, I hold that the same principles apply, but modified for your situation. Keep building on a solid foundation, don’t let it erode.

  • focus on a narrow set of domains at first, don’t open the firehose and learn a little of everything. Learn a lot about a few things: algorithms, a language, design patterns
  • do one thing well at first: it’s important to have a broad skillset, but if just have that you won’t be a real asset to any team. You need to either be a fantastic generalist (which only comes with a deep understanding of fundamentals and principles) or a great generalist with a specialty. In either case, really, you need to have a particular you can contribute.
  • learn design patterns: frameworks can bog you down, but design patterns are common abstractions that transcend the specificity of frameworks and the like. Furthermore, they tend to apply across languages and paradigms, so free you to move in that way, too.
  • learn a variety of languages over time: if you start with, say, JavaScript, and never leave, you’ll miss out on important structural and paradigmatic differences between languages.
  • implement things yourself: one of the best ways to learn something is to build it yourself. It’s important that you do this without expecting what you create to supplant the more-established technology. Build it because you want to understand it. If, in doing so, you come upon a better way, so be it. But in the learning stages, expecting to create something comparable to, say, React, will most likely just leave you frustrated. Build to learn, learn to build.

Build to learn, learn to build.

##Fin My practical advice is always a bit theoretical, so as a last offering to the reader, here are some highly-recommended resources to look at:

Questions, thoughts? Let me know in the comments!



  1. Although that would be pretty cool. [return]

Related: