Skills & Interests

Front or Back End?

I remember the first time recruiter asked me if I was a front or back end developer. It took me by surprise and I was unsure how to answer.

Full Stack

A short time later I learned the term “Full Stack,” and liked the sound of it. I am by nature a very curious person, always looking to learn more, and limiting myself to either the back end or front end is not appealing.

As it turns out, “Full Stack Web Developer” is the most popular term used for Developer Occupations (28.0%) in the Stack Overflow Developer Survey, with the closest runner up (“Back-End Web Developer”) coming in at a distant 12.2%.

Increasing Complexity

Staying up to date on all the technological developments going on these days is very challenging, and these challenges increase daily.

Given this, I have come to think that, these days, expertise is the enemy of the good.

I prefer to focus on knowing enough to get things done, and take the time to learn how to do things well when working on important projects.

Important Fundamentals

Essential knowledge of important fundamentals will always be transferable to other domains. For example, keeping things simple (KISS) and reducing redundancy (DRY) are important keys to high quality and success, no matter what sort of project you are working on.

AWD & RSS, and the Three CMSes

Integrating device detection into the three popular LAMP CMSes is a great way to exercise and add to knowledge of the full stack. But working on this project has made me realize a few things:

  • I enjoy programming, and make a point of doing it every day
  • I enjoy programming in JavaScript, and writing JavaScript programs that will run in a browser requires a certain amount of knowledge about the DOM, HTML, and CSS
  • With all due respect to designers and front end developers — heart you guys, seriously! — in my mind, writing HTML and CSS is not really what I would call “programming,” because those languages do not lend themselves to well-established organizational techniques1
  • So although I am knowledgeable about front end work I am more comfortable working on the server side of things, and that type of work fits well with my experience

Lesson Learned

The take-away for me is, I would definitely be happy doing back end development 100% of the time, but would not be happy doing front end work 100% of the time.

Full stack work is definitely challenging and totally engaging. So my ideal job would have a focus on back end work, and perhaps allow me to help out with front end work if and when the opportunity to do so arises.

But a job doing only back end development would be perfectly acceptable.


1 These organizational techniques include Object Oriented Programming (OOP) and even just breaking reusable code out into functions that are preferably parameterized. All modern programming languages like PHP, Java, JavaScript, Python, C++, Perl, and Ruby support OOP. And note that even ancient languages like Assembler, COBOL, LISP, and the more recent but still primitive shells (ksh, bash, csh, etc.) support breaking out reusable code into some kind of function, where as HTML and CSS do not, at least not yet.

A Passion for Maintainable Code

Thanks to a book, named Code Simplicity, I finally realized one of the main things I love about programming so much.

Finally, after many years, I have discovered my passion! And that is: writing code that is easy to understand and maintain, and this boils down to keeping code as simple as possible.

The book analyzes the value of software, the effort needed to maintain it, and the desirability of the changes, even though we cannot be sure what the nature of these changes might be.  And it comes to the conclusion that all code needs to change eventually, and the future cost of making these changes is more significant than the initial cost of development lose weight quickly.

The book made me realize that the real cost in software is not in the development of it, but in the maintenance.  By taking a little extra time and ensuring that code is maintainable, in the long run we save money.

And that is what I really enjoy about writing software.  Once I get a program to work once, I don’t like to stop there, the way some people do.  Instead, I like to take the time to look at what I’ve written and ask:

  • Does it make sense?
  • Could what it does be done any more simply?
  • Is there any cruft, any dead, unused code?
  • Will a new person understand it, quickly and easily?
  • Will a new person fix or enhance it, quickly and easily?
  • Will I understand it, quickly and easily, if I need to change it, in the middle of the night, a few years from now, or both?

To tell the truth, I actually have at times felt guilty about taking this extra step.  After all, the program works, why spend more time on it?  And of course there are times when I haven’t been able to take this extra step, and have regretted delivering something that I am not very proud of, something I know could be better, if only there was a bit more time.

This blog contains stories about the benefits of well-designed, easy to maintain code, and the hazards of poorly-designed, difficult to maintain code.

But I still encourage you to buy the book.