Technical Books and Beginners

My 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!

And I also wish to help dispel the myth or perhaps sense of fear that surrounds certain technical books. I know I held a sense of great unworthiness 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!

While of course this may be true for some texts, there are some great ones 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 that I think you could take away from Extreme Programming Explained as a new or newish developer that aren’t necessarily related to challenges you might immediately be facing.

Learn to Drive

Right off the bat, Chapter 2 offers a great analogy that I really appreciated even as I was reading it two 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 over arching metaphor of Extreme Programming, this sort of advice can apply to lots 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 that I find encouraging as I learn unfamiliar technologies and grapple with new and complex ideas.

For example, lets 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 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.

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.

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

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. Maybe less so than the other examples, as it’s not directly applicable to learning, 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?

In my experience with startups, I think it’s very 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 perspective.

The Wrong Books

When I started out learning to code in college and when I was at my first job writing video games in San Francisco in the 90s, the kinds of books we were learning from were either language definitions or giant books of syntax and algorithmic recipes. They didn’t make for what you might call “compelling” reading.

The coolest thing about any of those books was at my video game job, every single developer in the whole company had a copy of The C Programming Language by Brian Kernighan and Dennis Ritchie on their desk. It was sort of like a membership card to the club of C programming. And these were not lightly used books. I remember feeling really important every time I cracked my copy open to check how to dereference void pointers, which was probably every day. That’s not to say there isn’t value into working through these tomes. I think that I learned valuable skills like how to read the manual and how to solve problems using static resources.

And perhaps there aren’t any ‘wrong’ books. Maybe things go over your head but maybe they are in there and maybe, even if you have no professional experience, something will lodge deep in there and pop up at a surprising time! Who knows.

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.

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 that it required a more advanced skill set than you currently have, I hope you have been disabused of this disillusion. I hope that 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 that 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

If you have any others, tell me!

Originally published on the StrideNYC blog.
Check it out, they’re hiring!