At my first programming job, writing video games in San Francisco in the 90s, I was thrown into the deep end of some C and C++ hoopla and I turned to the well known and venerable book “The C Programming Language,” by Kernighan and Ritchie, for salvation. While it did help me make heads or tails of what I was doing, it didn’t make for compelling reading. Beyond syntax and algorithms, this and some of my other first technical reads didn’t easily translate into lessons I could use anywhere but with a C compiler. This initial introduction to technical writing during my formative years and impressionable youth turned me off from reading technical books, and that has unequivocally been a mistake, a failing, a missed opportunity, a faux pas, and many other bad things. I’m writing this to urge you, _**yes you, dear reader**_, to not fall into the same trap!
It’s easy to start in the wrong place, or to be hamstrung by misconceptions of your own technical ability. I know I held a sense of great unworthiness whenever approaching technical books for far too long, feeling as though I needed to ‘master the basics’ before moving on. As beginners and learners, we often have that sneaking and unpleasant sense of impostor syndrome whispering over our shoulder: ‘hahahaha, what business have you reading this great and learn-ed text?! You still don’t know how to write while loops!’
Of course this may be true for some texts, there are some great places to start out there for all of us, regardless of how far along we are in our career, our mastery of syntax, or our experience level. I’m writing this to empower you, _**yes you, dear beginning programmer who maybe doesn’t yet know what a while loop is**_, to pick up a good technical book and let it direct you, inform you, and enrich your understanding of what it means to write software.
Extreme Programming Explained
One possible place to start is Extreme Programming Explained, by Kent Beck with Cynthia Andres. Here’re a couple of things I think you could take away from Extreme Programming Explained (hereafter referred to as XP) as a new or newish developer that aren’t necessarily related to challenges you might immediately be facing in your day-to-day.
Learn to Drive
Right off the bat, Chapter 2 offers a great analogy I really appreciated even as I was reading it a couple of days ago.
“Driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way.”
In talking about an overarching metaphor of Extreme Programming, this sort of advice can apply to plenty of things beyond just the process of software development. Inherent in the idea of continual corrections and adjustments is a requirement to be open to new things, to be regularly evaluating your current position. These are both things I find encouraging as I learn unfamiliar technologies and grapple with new and complex ideas.
For example, let’s say you’re learning React! Rather than starting some tutorial and blindly stumbling down the prescribed path, maybe it makes sense to start out with the tutorial, digress into some javascript review, go back to the tutorial, start the tutorial over, read a blog post, and then continue on with the tutorial…
Or I don’t know, maybe it doesn’t!
But rather than setting things in motion and expecting to come out on the other side having learned and mastered a new technology, assuming an active role in your own learning seems to make a lot of sense. Additionally, it makes the inevitable detours we all face part of the journey and not a disappointment with the potential to derail you.
Start Where You Are
Where do you start when you try to learn something new? That’s a particularly hard thing, especially for me. I get lost almost immediately in trying to figure out where I SHOULD start. This is dumb of me and thankfully, Mr. Kent Beck has something to say about this in his fine book.
“You are already developing software. You have already started. XP is a way to improve both your development process and your experience of it. To do XP, you start where you are and adapt by adding practices that meet your goals and express your values.”
I love it! You start where you are. Potentially platitudinous? Perhaps. Profound? Probably. Perfectly apropos? Precisely.
Regardless of applicability to agile processes or team, I can take this and apply it to where I am as a learner of a language or a framework. I am where I am and any step I take forward will be incrementally positive. I am already learning. I am already programming. Adopt techniques and strategies for getting better. If they meet the goals, keep doing it! This is a perspective I wish I had when starting out.
Great Code Is Good For Business
Maybe less so than the other examples, as it’s not directly applicable to learning or “how code works,” I do think Kent Beck’s ideas about how software development serves business goals are interesting and informative, especially to someone who may not have had the chance to write code professionally. How do you start to get a sense of what the value of your efforts in crafting code is going to be? How do businesses and developers interact in order to create value? What are the constraints a team of developers might face as determined by a finance department or a product team?
“Somebody has to pay for all this. Software development that doesn’t acknowledge economics risks the hollow victory of a ‘technical success’. Make sure what you are doing has business value, meets business goals, and serves business needs. For example, solving the highest priority business need first maximizes the value of the project.”
In my experience with startups, I think it’s easy for a new developer to jump into a code base and, with good intentions, aim for “technical success.” In the worst cases, technical success is sacrificed for technical novelty. Either way, the business goals wind up being secondary which is disastrous for a business which doesn’t yet have a business! As a developer just starting out, helping to frame your practice and skills in the context of a resource that will help a company grow will give you an advantage in your work and your ability to play a strategic role as a programmer.
Conclusion
Good technical books about programming and software are valuable to you at any stage of your career. If you were afraid of diving into one or felt it required a more advanced skill set than you currently have, I hope you have been disabused of this disillusion. I hope I have identified the kinds of lessons you might find in some of these books that are relevant regardless of your experience.
Here’re some other books I think you could incorporate into your practice and learning early on.
- TDD By Example, also by the illustrious Kent Beck
- Eloquent Ruby, by Russ Olsen
- Practical Object-Oriented Design in Ruby, by Sandi Metz
Nichol Alexander
