Category: Uncategorized

I’m afraid that I still have a long ways to go as a programmer—obviously—which means that there’s still a limit to the amount of valuable programming advice I can give anyone. However, I do have some broader life experience that might be helpful to anyone who’s starting out on the journey of trying to accomplish something new or pick up a new skill.

Something I learned while I was writing my first couple of books was that sitting down to start writing for the day is hard nearly every single time, but the experience of writing is nearly always really, really rewarding once you actually get started. In fact, it’s so rewarding that I often find myself writing for much longer than I originally planned on when I set out to meet my goal for the day.

Most of you can probably already see where I’m going with this, but it’s worth saying anyway. Setting a series of daily goals and sticking with them week after week is the absolute best way to master something new or accomplish a really big task.

I suspect there is some variation from one person to the next, so you may find that what works for me isn’t quite the best thing that works for you, but I’m going to just go ahead and share my system for accomplishing things and hope that there’s something there you can draw from as you go about starting on your new goal.

It’s been my experience so far, that I have a real tendency to want to dive into something at the very start of a new project or a new goal with both feet. That generally means that I put a ton of time into whatever it is I’m working on for the first few days and then end up burning myself out because that level of effort isn’t sustainable.

I once heard willpower described as an afterburner, as something that could get you somewhere really quick, but which nobody could sustain for very long, and that has been my experience with a lot of new projects that I picked up before I fully appreciated the value of setting small, relatively easily obtainable goals and sticking to them as a way of accomplishing something much bigger.

I think the reason that small goals work so well for me is that it requires a lot less willpower to accomplish them on any given day. It was almost always very difficult to make myself sit down at the computer if I knew that I was signing up to five or six hours of writing on top of whatever else I had going on that day. Alternatively, telling myself that I was only going to write 250 words was something that was much less intimidating. That made it easier to do, which meant that I was more likely to sit down and hit that daily goal on a consistent basis.

I’m sure that there are some people out there who would say that it’s not worth even sitting down to write if you’re only going to rack up 250 words, and on the face of it they aren’t wrong about how long it takes to write a book if you only manage to get 250 words a day written.

If the average book is 80,000 words, and you only managed to write 250 words day, then you’re looking at 320 days to write a novel, and the average person seems to have a hard time planning for something that far in advance.

However, if you are consistent about your writing goal, then that means that you’ll be writing at least five or six days a week, so really you’re only a year or so away from having finished your first novel. Generally, unless something tragic and unforeseen happens, the next 365 days are going to pass by whether you are working on your book or not. The real question is what you’re going to have to show for the year once those 365 days are firmly in the rearview mirror. In my experience, creating a consistent habit via small, achievable goals is the best way to reach a writing goal, or just about any other goal you can think of.

Even better, the fact that most of us set goals for something that either we already enjoy but have a hard time getting to or something that we can learn to come to enjoy, means that more often than not you’ll continue working on your goal even after you hit your target accomplishment for the day, which always meant for me—at least when it came to writing—that I generally finished up my books much more quickly than I expected to when I set out with my initial, purposely small and achievable goal.

I think that is the bulk of where the magic is, but there are a few other pieces of advice that may help depending on your situation. For religious reasons, I try to avoid doing anything that could be considered work on Sundays, which means my default goal for things that could be considered work is generally six days a week. However, there are times—often when my life is getting particularly hectic and I have commitments that are hard to plan around—where I’ve found that I get a lot more done and am much more consistent with achieving my weekly goals by setting out to work on my side project four or five days a week.

The human mind is sometimes prone to focus on the wrong thing, which means that when I fail to hit one of my goals for a specific period of time, I’ve historically tend to obsess about the failure rather than being pleased with all of the days where I actually managed to make progress. By giving myself one or two days a week where I had permission to deal with all of the other stuff that life was throwing at me, I stopped setting myself up to miss one of the days that I was ‘supposed’ to be making progress and then going into a negative spiral that stopped me from picking things back up on the next day.

I have another trick or two that I really ought to share while I’m thinking about it, but I am far past the amount of time that I told myself I was going to work on this particular blog post, so the rest of my strategies around accomplishing goals will have to wait until next week.

Until then, good luck with your own code-writing endeavors.

If you’ve read my first two posts, you already know that I prefer reading to watching videos when it comes to learning stuff, so this may come as a surprise to you all, but I’ve made an instructional video.

As I’ve been working through various JavaScript tutorials, a recurring issue has been that stuff is sometimes being done in an order that didn’t initially make sense to me with my C++ background.

When I asked about the oddities I was seeing, I was told that the asynchronous nature of JavaScript was the cause of everything.

If there is one thing that more than 10 years of accounting has taught me, it is that more often than not it’s the stuff that you just think you understand that really trips you up in the biggest ways, so I set up to understand the asynchronous nature of JavaScript well enough that I would be less likely to have it come back to bite me later on.

As chance would happen, shortly after I started to get a decent handle on which parts of JavaScript were synchronous and which parts were asynchronous, we ended up needing some content for one of our weekly development lunches. Being generally willing to pitch in when the need arises, I offered to explain my findings to the development team.

When I shared what I’d learned with some of my co-workers, they were really positive–both about the quality of the information, and the way that I’d presented it. So much so, that they convinced me that I needed to turn my presentation into a video and upload it to YouTube.

It’s taken significantly longer than I was expecting to it, and there was a much bigger learning curve than I was prepared for on something that was just supposed to be a quick side project, but it’s done, and if you’ve ever wanted to have a better understanding of how JavaScript handles asynchronicity, this is the video for you.

Here’s Dean’s first JavaScript Video

Here’s the slides that I used to create the video

Here’s the transcript of the video

I would love to have you link all three of these items around to anyone that you think might benefit from the information–just please leave the links back to WritingCode.net in place so that I get credit for my efforts.

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.

Past experience has shown me that the only way to start a new writing project is to just sit down and start, so this is me starting.

Welcome to Writing Code, an online account of someone who dropped out of programming in college to become an accountant, then in turn dropped accounting to write novels full-time for four and a half years, only to go back to accounting and then decide to try his hand at programming.

Given an intro like that, it would be reasonable for you to assume that I’m the kind of person that doesn’t stick with anything for very long, but the opposite is actually the truth. I was an accountant for nine years before I quit so that I could write full time, and I’d been writing books for at least 10 or 11 years before I quit accounting so that I could write full-time.

I’m really good at accounting, and there are aspects of accounting that I really like, but it was never one of my loves the way that writing was. In the same vein, I did reasonably well as a writer, and would still be doing that if not for the fact that most people who want to read my books decided that they were unwilling to pay for the opportunity to do so (once my books made it out onto the torrent sites).

I feel like I’ve given both writing and accounting a solid decade each out of my life, and at my most recent accounting job, I’ve ended up having to delve into the technical side of the business much more than you would expect out of a normal financial controller.

It turns out, that I’m much better at that than anyone at work originally suspected I would be, so I’ve decided to see if I can pick up enough software engineering expertise to broaden my horizons to where I could eventually have a startup of my own, or failing that, take advantage of having expertise in two domains and parlay that into a higher paying job than what I could get as either just an accountant or just a programmer.

I hope that you’ll find some use, or some enjoyment following along as I chronicle the parts of my transition that are safe for me to comment on.

It’s probably helpful for you as the reader to have an idea both of how often I plan on updating this blog, and my rough level of expertise as I start this endeavor. For the first, my goal is to roll out weekly updates. The updates will probably be fairly short to start out with given that most of my insights will revolve around how coding interacts with accounting, but as I get deeper into this new world, hopefully the updates will get longer.

As for the second, I’m not quite starting at square one, but I’m pretty close to that. I had a year and a half of C++ programming back in college. Since then, at my current job, I’ve become fairly adept at understanding SQL, both when it comes to getting the data out of the tables, and with regards to how to design tables in order to address the underlying needs of whatever problem it is that I’m trying to solve.

More recently, I’ve completed tutorials in Python, and Java, and I’ve begun a tutorial in JavaScript. That means I’m familiar with concepts like loops and functions, and that I’ve played around a little bit with objects and classes, but that there is a whole world of things that right now I don’t even know that I don’t know.

So, if that sounds interesting to you — either because you’re considering becoming a programmer, or because you’re managing junior developers — then I hope you enjoy the ride here at Writing Code.