It may seem a little unorthodox to start out my second post with a book review, but that’s exactly what I’m going to do.
Historically, as I’ve decide that I want to learn something new, my go-to route for getting my arms around the subject matter has always been to spend a lot of time researching. Back in the day, that meant I spent a lot of time in books, but the world has come a long ways since then.
It seems like, for the most part, if there’s something I need to learn I can find the information I’m after on a blog or other website for free. Obviously, there are a lot of instructional videos on YouTube, but for the most part I try and stay away from videos. That isn’t to say that there is a value there, but I tend to read quite a bit faster than most people are able to talk, or at least faster than people naturally talk when they’re discussing something highly technical.
I’ve been told that there are some really useful browser extensions that let you speed up videos, and I have it on my to do list to go download a couple of them and find one that works well for me, but in the meantime I’m just able to consume a lot more material in written form, so that’s going to form the bulk of my initial approach.
Prior to being told that it would be possible for me to transition from finance to development at my current position, I was doing a lot of research around what was involved in becoming a self-taught developer. Somehow, I ended up on YouTube looking for something unrelated and one of the videos in my feed was from a self-taught developer. He seems to be doing quite well for himself, and he highly recommended the Complete Software Developers Career Guide by John Sonmez.
The recommendation was glowing enough that I went ahead and downloaded the sample to my phone, and ended up hooked.
As a side note, it’s become a lot harder for me to be willing to pay for books over the last few years since I started writing and getting paid for my own books. It’s not that I don’t see value to someone’s effort that they’ve put into writing a book, and I’m not condoning pirating someone’s book, but a book has to be really stellar — or at least look like it’s going to be really stellar — before I’m generally willing to pony up any of my hard-earned money and purchase it.
Hopefully that gives you an idea right out the gate of how impressive this particular book was.
It’s a huge book (something like 700 pages), that covers a whole host of different topics — essentially everything you could reasonably expect to need to understand at any point of a development career — but the author stayed away from all of the technical details that are likely to change over the next few years and decades, and stuck with evergreen analysis of the high-level levers that come into play when you’re trying to make a living in this particular field.
He discusses the relative pluses and minuses of being a self-taught developer versus going and getting a traditional computer science degree versus going to a boot camp in order to get your start in the industry, and then moves on to a bunch of other really useful topics only a few of which I’m planning on highlighting in this write up.
Out of everything that I read, the piece that probably impacted me most was the author’s attitude when it came to arriving at your value as a developer. I think it’s really easy for most people whose role isn’t primarily an interpersonal function to think that salaries are set entirely by the law of supply and demand, but that just isn’t the case.
The truth of the matter is that supply and demand does play a really big part in how much people are making across an industry, but there is a lot of individual variation inside of any industry, and that all comes down to the relative negotiation skills of the employee and employer.
Salespeople seem to almost instinctively grasp that concept, but accountants and developers — at least so far in my experience — are much less comfortable with negotiating salaries, which is generally to their detriment.
I’ve been in an organization where I was so highly valued that I didn’t have to ask for raises, but that type of scenario is vanishingly rare and is predicated upon the employer being very aware of the value that a given employee is creating, and being very concerned with ensuring that the employee can’t get a significantly better offer somewhere else for the same kind of work.
For everyone who doesn’t happen to be in that enviable situation, the author’s strategies on negotiating your salary when considering a new position, and demonstrating your value in your current position is the kind of thing that could be worth, quite literally, hundreds of thousands of dollars over the course of someone’s career.
I fully intend on going back through this book in a year or so and seeing what additional value I can derive from it upon a second read—once I am a little further along in my development career—but for now there are two things that I’ve already implemented which I expect to drive a significant amount of value for me professionally over the long term.
The first item is that I will be doing a weekly status report to my development manager to ensure that he is always very much aware of what I’m accomplishing and the value that I’m bringing. Human nature is such that even when we know something to be true, if it’s not immediately in front of us, other concerns or truths end up taking priority.
In the past, I’ve often found myself so busy with the workload in my finance positions that I felt like I couldn’t justify taking 15 or 20 minutes at the end of every week and writing up a report of everything that I’d accomplished, but while there are a few unique individuals who will understand both what you’re accomplishing and that you’re trying to put the company’s interests ahead of your own by dedicating every possible moment towards staying on top of your existing workload, that very much seems to be the exception to the rule.
Given all that, even if you have the best boss in the world, and especially if your current manager doesn’t really understand what’s involved in doing your job on a day-to-day, week-to-week, basis there is something to be said for making sure that you’re checking in on a regular basis with that individual and showing them just what it is that you’re accomplishing.
The second item that I’ve already begun implementing from this book, is the blog that you’re currently reading. One of the author’s points, which really resonated with me, was that it’s a lot easier to demonstrate value internally inside of an organization if the perception inside the organization is that you are externally valued.
While this blog initially isn’t likely to instantly drum up consulting work or result in job offers coming into my inbox out of the blue, over time—as I start to master some of the important areas of software engineering—it gives me a chance to both demonstrate that mastery, and create an avenue that people who are looking for my skill set can use to find me.
So there you have it, I wholeheartedly endorse The Complete Software Developers Career Guide, and hope that you go get a copy so that you can begin implementing the kind of strategies that will lead to higher lifetime earnings and a more satisfying development career.