I ran into a problem recently when trying to run a fix script with my then-boss.

It’s been a couple of weeks now, but to the best of my memory, we had queried the database for a list of records, and then were wanting to insert into another table using one or more pieces of data from the list of records.

It seems like an easy problem to solve.

var gr = new GlideRecord(‘table_name’)

Then add your query parameters and run gr.query()

Finally, you then use while(gr.next()){} to step through the records, and inside of your while loop, you create a new GlideRecord object that you can use to insert the new record.

However, after several iterations, we weren’t able to get the insert to work while it was nested inside of the while loop.

My workaround for that is to step through the records using the gr.nex(), and push the information I need from the records onto an array (or an array of objects). Then, further down I can step through the array and do whatever inserting I need to. That worked without problem, and more closely mirrored what I do with function calls (since you can only return one item, if I want to return anything complex I end up placing the information I need into an array, an object, or an array of objects, and then just returning that).

Hopefully that will save some of you fifteen minutes at some point when you avoid replicating the problems we had.

Given that I’m in the middle of a job search right now, getting posts up displaying my skills is more important than sticking to a regular posting schedule.

Due to that, I’m going to try and get a bunch of content posted in the next few days even if it means that I ultimately end up having a gap in posts at some point in the future.

For my first ‘show my skills’ post, I’m simply going to link to a post I wrote for the Lumagent blog that recently went live. It describes how I went about setting up an automated time sheet reminder inside of ServiceNow.

You can find the post here:

Creating Email Reminders For Missing Time Sheets

Hello, and welcome to another week. The last several week’s worth of posts have been more high-level items that I’ve seen prove helpful while trying to excel as an accountant and as a writer, and which I assume will prove helpful as I’m transitioning to full-time developer.

This week’s post is going to be a bit of a change from that, but before I get into that it’s probably worth explaining some of what’s going on. I’m actually several weeks ahead as far as writing posts go. There are several things that play into that.

When I read the Complete Software Developer’s Career Guide and he recommended so highly getting a blog started, I knew that I needed to start writing posts immediately or I would be risking having that idea end up in the trash heap of other great ideas that I never made it around to doing anything with. So, I started immediately. The fact that I don’t have an actual blog up yet (it shouldn’t be too hard in theory given that I’m just planning on using WordPress), combined with the fact that Katie hasn’t had much—if any—time to do an editing pass over the posts means that I can’t post the entries I’ve written so far even if I wanted to.

As it turns out, I don’t want to start posting them until I’ve got a good backlog of entries both written and edited. My theory is that once I start posting I need to do everything possible to make sure that I stick to my announced schedule of one time per week, but I’m very conscious of the fact that life (especially with baby #4 on the way) sometimes gets in the way of those kinds of schedules. By having a backlog of posts (and trying to write more than one post from time to time in a given week as a way of further building up that buffer), I’m putting myself in a position where even if I miss writing for a week or two I’ll still be able to deliver as promised to my blog readers.

This week I finished my Javascript tutorial at Codecademy.com. That means I’ve now been through the tutorials for Java, Python, HTML, CSS and Javascript. In theory that also means that I have the foundational knowledge to start building stuff.

That’s nice, but it also means that I’ve moved from the orderly, incremental world of progressing through tutorials to the messy world of figuring out stuff that I’ve never done before.

I tend to be more focused on the outputs than I am on the inputs (as you can probably tell from my posts so far on goal setting). That works really well for the most part, but when I’m trying to build something from scratch, there are inevitably going to be some times where I put a lot of time into a project and don’t have much to show for the effort—or at least that’s what it feels like.

In reality, there is a lot of learning what doesn’t work so that I can rack up the small victories as I find things that do work, but that learning is a bit harder to measure. Things are further complicated by the fact that I don’t really have any good idea of what will be involved in getting something new built.

I know roughly what I want the end result to be, but I don’t have any really good idea what is going to be involved in getting to that point. That tends to make my victories feel even smaller.

All of which probably sounds like just a bunch of whining, but that’s not what it’s meant to be. There is some pretty compelling research that I saw at one point which indicated that we actually feel emotions first, as far as order of things that happen, and then only after that is it that our conscious mind reflexively tries to decide why it is we feel that way. Given that, I find that it’s really, really valuable to occasionally step back and think about what it is I’m feeling and why I’m feeling it. It’s even more valuable when I do so with the understanding that my first thought around why I’m feeling something — the reflexive response — usually ends up being wrong.

That was a little bit of a rabbit trail, I suppose, but the piece that I was really trying to get across is that with the ever mounting push to try and get my arms around development, and get my first side project app live, it’s getting harder to fit in the time that I’m supposed to be dedicating to writing a blog post each week.

The upside to all that is I now understand what’s going on, so I’ll be better positioned to make sure that I get the blog post written early in the day rather than leaving it until the last minute.

All that being said, as my skill set has started to expand, I’ve been able to rack up a few tiny accomplishments that I’m proud of, and that I want to report back to my readers on. Here are the things that I ran into and managed to solve during the last week.

Firstly, I noticed a few weeks ago that there was a problem with my writing website — the one that is directed towards people who are reading my novels. The homepage is supposed to have this attractive graphic of seven different books that readers can get for free by signing up for my mailing list, but when I went there to fix a couple of other problems that have been lingering on the website for several months while I was working on my provisional patent applications, I noticed that the graphic had disappeared.

I tried everything I could think of to find the graphic on the website in the WordPress backend, but didn’t have any luck. I assumed that word press have fallen over somehow and deleted that image, or that I somehow deleted it at some point in an effort to save disk space and bring down my hosting costs.

I couldn’t find it in my dropbox account (I really love Dropbox, by the way. It’s not perfect, but it’s been hugely helpful when it comes to keeping stuff synced up across multiple computers. If you don’t have an account already, you should try them out. If you use this link then Katie or I will get a little bit of extra storage on our accounts.)

Back to the problem with the website: I asked Katie to dig up the original file from off of her desktop, but she’s been extra busy trying to keep our kids alive lately, so she hadn’t made it to that yet, and I had just chalked it up as something that was going to have to stay broken for a few more weeks or months.

A little while after that, I was trying to get QuickBooks installed on a laptop for a new employee in the accounting department. I don’t remember why I felt like I needed to test the browser on her machine, but at some point during that process I opened up chrome and went to Dean rights.com. Imagine my surprise when I saw the big graphic that I thought had disappeared sitting exactly where it was supposed to be on my website.

To make a long story short, it still wasn’t working on any of my machines but I finally had the thought that I should inspect the site and see if there are any errors on the page. As it turned out, there was an error:

err_blocked_by_client

Some searching online turned up that the likely problem was some kind of ad blocking software, which matched up really well with the fact that I recently installed an ad blocker extension in chrome. I turned the ad blocker off, which fixed it for me, but didn’t address the fact that it would be invisible to anyone else who had an ad blocker running on their browser.

I could live with that if there wasn’t any other solution, because at least some of my traffic would be seeing the graphic telling them about the opportunity to get a bunch of free books, but it still wasn’t ideal, so I did some more digging. As it turns out, if you have a graphic on your site with the word ad anywhere in the name, the ad blockers are smart enough — or at least this one was — to strip that out of what is displayed.

I renamed the graphic, re-uploaded it to my blog, and that solved that problem.

The next problem I ran into involved moving files in the terminal on my MacBook. The development manager at work has been really kind to serve as a resource for me as I’m trying to get my legs under me as a developer, and this last week he agreed to help me set up a skeleton of an app so that I could experiment with it rather than breaking stuff at work.

As part of that process, he told me to from one spot to another, and then got distracted by someone knocking on his front door. I wanted to show as much initiative as I could, so I looked up the copy command online and typed it into the terminal for him to check when he got back to where we were working.

For all of you much more experienced UNIX or Mac OS users, the obvious answer is the cp command to, which I was smart enough to arrive at as the proper route forward, but I used the -r flag on it. I showed the development manager, he looked at it for a second and said he thought that would work just fine (it turned out that when he did the same step he used the move command), but several steps later in the process I wasn’t getting the right outputs.
I still don’t know a lot about programming, but anyone who spent very much time in a controller role in an accounting department inside of a small organization that’s evolving rapidly tends to pick up some pretty good problem-solving skills. A few minutes of investigation while the development manager was dealing with some small fire that was happening back at the office showed me that the files back in the directory that I’d copied from were giving the correct output.

Logically, that seemed to me like an instance where the copy must have gone wrong, so I went online to see if I can find something that would confirm my theory. As it turns out, cp -r doesn’t maintain symbolic links, but cp -a is a recursive copy that does maintain symbolic links in the files that are copied over

Copying the original files into a third directory confirmed that cp -a did the trick, but then I had the problem of trying to figure out how to not have to redo the last hour or so worth of work. I decided to copy the files from my working directory up to one of the earlier versions that had the symbolic links working– doing so with the -r flag so that I wouldn’t mess up any of the symbolic links in the earlier version– and then I copied everything from the earlier version directory — which now also included the latest versions of the files — back into my working directory — this time using the -a flag.

Both of those victories — all three if you include fixing the graphic that wasn’t working my website — were pretty small things, but it was nice to be getting to the point where I can at least troubleshoot some of the problems by myself.

A few other things that I learned this week as well:
If you’re watching a tutorial and they use yarn, there’s a very good chance that you can get the same result just using npm.
If you need to know what’s running on a particular port, you can use this command from the terminal: sudo lsof -l tcp:<port number> where <port number> is the actual port number you’re wanting to check.
A lot of times when you tell a process to run from the terminal it ends up sort of running, but not being quite what you need because you messed up on one of the earlier steps. I didn’t realize when I was happening, that the process was still running, I would just keep opening new terminal windows because I was no longer able to use the existing terminal window to do anything. In those instances, when you want the process to stop, you can use ctrl-C to cause the process to exit gracefully.

Lastly, back when I was working on creating that skeleton with the development manager, there was a piece of the tutorial we were using where I was supposed to build the hit the app on my local box via a browser and get some kind of stock splash screen.

The first time through the tutorial, I didn’t get that splash screen, but for some reason I didn’t think much of it. That’s a big mistake, and frankly I know better than that when I run into a similar problem in accounting, so I should’ve known better than that now when running into that kind of issue in a development context.

If something doesn’t work early on in a process that you don’t understand, and run through the steps up to that point again. It is highly unlikely that something broken earlier in the process will magically fix itself later on in the process.

That’s it for me for this week, but I hope someone out there eventually comes across this post and gleans a few useful nuggets from it.

Welcome back to my third installment on using goals to create habits that transform your life. So far, I’ve covered the value in making the goals small so that it’s less painful to sit down and do them, and the value behind having an accountability partner to whom you’ve defined the goal, and then implementing some other kind of tracking that will allow you to look back and see what you’ve accomplished.

I a started out today having a very specific thing I wanted to cover, but we’ll see how well I stick to that.

My experience in the past has shown me that creating new habits that leads to some kind of trackable results that you believe — rightly or wrongly — will change your life can be very addicting. On the one hand, that’s really good. That very addicting nature means that once you get started it’s the natural tendency to keep at it. Even better, once you’ve had success with a few new habits, you become more likely to add even more habits.

I think that’s probably at least part of what is driving the life hacker craze (I use craze in the best possible way here), but that addictive nature means that you need to go into this kind of thing with your eyes wide open. Firstly, make sure that you have a clear understanding of what you’re odds are of accomplishing the thing that you’re setting out to do, and the relative benefits of achieving your goal.

If I set a goal to increase the amount of distance I can run without getting tired and out of breath, barring really unusual circumstances, I can say with a relatively high degree of certainty that over time I will accomplish that exact goal. If, on the other hand I set a goal to become a world-class marathoner, my odds of successfully achieving that particular goal are very, very small.

Getting enough sleep, eating a healthy diet, and gradually working up the amount of time I spend exercising — more particularly running — should really be all that would be involved for accomplishing the first goal. When it comes to the second goal; however, have to do all of that on and much, much larger scale. In fact, I think it’s pretty safe to say that the very top percentage of professional marathoners couldn’t put in enough hours training to remain in their peak condition if they were simultaneously trying to hold down a traditional 9-to-5 job.

That means that in order to become an elite marathoner, I would have to dedicate enough hours to training in order to reach the top levels of performance which are available to someone holding down a traditional job, then get sponsorships or some other kind of outside funding that would allow me to transition into running marathons as my full-time job. Nothing there is completely undoable yet, but there are genetic aspects of simply can’t be overcome by someone who didn’t when the genetic lottery.

Everyone loves a story about someone who refused to quit pursuing the dream, and as a consequence overcame tremendous odds or handicaps to achieve greatness, but as a society we tend not to look at the other side of that coin. For every person who set out to achieve some incredibly unlikely goal, and who ultimately succeeded, there are probably thousands or tens of thousands of people who put in very similar amounts of effort but who failed and were left with nothing but regrets, bitterness, and a lot of wasted time to show for their efforts.

Again, I think having goals is great, and that most people ere on the side of not setting big enough goals rather than on going after something that is too big into unlikely, but the problem is very real. It’s especially big when you talk about goals that revolve around making a living in entertainment. For every success story of an actor, or an author, or comedian who make it big there are a lot of people who don’t manage to ride the wave of luck and opportunity to becoming a superstar.

So, just be aware of the opportunity costs of what you’re giving up to pursue a particular goal versus both the payoff, and the relative odds of success. Deciding that you want to become an accountant as a way of changing careers is going to be a fair amount of work, but it doesn’t have to consume your entire life. In a similar vein, it’s not going to the to income in the tens of millions of dollars per year range, but if you are of at least average intelligence and are willing to put in the work — and possibly get a degree to backup the fact that you’ve learned what you need to learn – the odds that you’ll succeed are extremely high.

So, if I had to summarize that first point I would say it’s all about not setting goals that are so big and unlikely to result in success that you look back years later wishing that you hadn’t started on that path in the first place. I could probably stop the blog entry right there and the like I accomplished what I set out to accomplish, but it’s also worth mentioning that you can end up with the same kind of problem even if your goals are more reasonable.

You can fashion a whole bunch of really reasonable, high-value, likely to achieve goals — goals that you ultimately end up achieving — and still in the experience bitterly disappointed and unhappy once you realize that your goals didn’t actually move you towards the things that were most important to you. Make sure that as you are setting out your goals that they align with your core values, and that you are leaving time for the things in your life that either can’t be replaced, or that you don’t want to replace.

The thing that most immediately suggests itself as being in that category is your relationship with your family and your closest friends. Supporting those relationships shouldn’t mean that you have to spend dozens of hours a week at bars or doing things you actively hate to the detriment of goals that you know will help improve your quality of life, but you don’t want to fill your life up with a bunch of small things that cried out your ability to achieve the big things.

If it seems like I just gave conflicting advice, I suppose I did to some extent, but I really wasn’t trying to say don’t pick goals that are too big or goals that are too small. What I’m trying to say is make sure you’re picking the right goals and if you’re going to focus on something that’s really usage and really unlikely to result in success, make sure that you’re okay with what your life will look like if you don’t succeed at that goal.

That’s it for this week, I hope these posts are proving helpful or at least giving you cause to think about stuff in ways that you haven’t thought about them before. I’ll be back next week with more to say.

This is just a quick post to apologize for the big gap in posts between my last post and this one. We had a baby towards the end of the year, which I knew was coming, and I had a number of posts written and saved up to bridge what I was fully expecting would be a very busy few weeks/months, but then things went even further off the rails than I was expecting them to.

A week and a half after our baby was born, I was fired, and I was forced to spend the next 2 months looking for a new job. Give how recently I had made the switch to development, I put everything but looking for work and learning more programming onto the back burner.

I’d like to say that things have slowed back down and that I’ll be able to return to a more regular schedule of posting, but we’re now one emergency trip and a totalled vehicle later, and life is still a lot more difficult than it was back when I first made the switch to development.

That means that I’m likely to continue to be more irregular with my postings than I would like to be, but at the same time, I’ve been learning a ton, and I want to document my insights (for myself if for nobody else), so I’m going to attempt to resume writing posts as often as I can.

One change that I’m hoping will help increase the throughput of my writing is that I’m going to reduce the editing process that I’d been using previously. That means that it’s very likely that some typos are going to get through, but hopefully my current audience will be understanding of a few mistakes and will focus more on the core ideas of the posts.

I’m happy to be able to sit back down and write a little bit more about my strategy for achieving goals — whether they be writing books, learning to code, or just about anything else you can think of.

In my last post, I talked a lot about the value of setting small, easily obtainable goals. I also talked about the importance of setting your goals such that you are accomplishing them often enough during the week that they naturally lend themselves to the formation of a new, productive habit.

It’s worth mentioning in passing that I read some research somewhere relatively recently that said that the old ‘truth’ about doing something for a month being sufficient to form a habit wasn’t actually accurate. Some people, it turns out, form habits much more quickly than that; others take much longer than a month to hardwire in a new habit.

I don’t remember where I saw the research, or I would provide a link to the authors of the article, but one of the things that stuck out in association with all of that was the fact that something is in the habit until it starts to become extremely easy to do, so keep that in mind as your working on your small, daily, achievable goals. It may take you a lot longer than you think it should for working on your project (or your new skill) to become second nature, but if you stay at it long enough—something that’s a lot easier to do if your daily goals are reasonable—it will eventually become a habit and it won’t be so hard to continue making progress.

The other main aid to making progress that I want to talk about is almost certainly something that you’ve heard before, but you may not have ever put this particular strategy into practice, or if you did, it’s possible that you didn’t realize at the time how much it was contributing to your success.

I find that it is vital in almost all of the goals that I set to have an accountability partner, which is to say someone to whom I report my progress or lack thereof to on a regular basis. You may or may not need to tell this person that you are using them as an accountability partner—I find that oftentimes reporting back to the person can be done in a very organic matter—but it definitely needs to be someone who’s opinion of you matters enough that you aren’t going to want to have to tell them that you failed to achieve your daily goals for the week.

If you find that you’re not being consistent with reporting back, then there are a few things that you can change up which may help incentivize you to be more consistent. Firstly, if your use of them as an accountability partner has been very informal, then it probably would help to formalize that. I sometimes use my wife as an accountability partner for things that I want to accomplish, but which she doesn’t really care about. In those instances it’s generally worked to keep my reporting back to her fairly informal so that she doesn’t feel like I’m expecting a lot of effort from her following up on something that she doesn’t think is important, but I am a naturally goal-driven individual, so I tend not to need a lot of external motivation to work on things that I’ve put down as goals.

Maybe it should go without saying, but the less your accountability partner cares about the things that you’re trying to achieve, the less value they will be able to provide with regards to helping motivate you to accomplish your daily and weekly goals. In the extreme, worst-case scenario having someone who thinks that the things that you’re trying to accomplish are bad or distasteful would serve as an active disincentive to accomplishing your goal.

I’ve heard it said that a goal that isn’t written down is nothing more than a dream. I’m not sure that I completely agree with that, but writing down a goal does help make it more real for most people. There is undeniable value in that. Verbalizing my goal to someone I respect tends to have the same positive kind of benefit of solidifying what I’m going to go do. There may have been times where I didn’t write my goal down or tell anyone and still managed to successfully create the habit of regularly working towards that goal, but by far and away, my best results have come when I have clearly defined the goal to myself, or someone else, and tracked my progress towards that goal.

You doubtlessly all caught that I just slipped one more strategy in there at the end, but just in case someone didn’t, I think that tracking your progress toward your goal is hugely valuable. When I was writing books, tracking my progress was relatively easy because all I had to do was log how many words I wrote each day. It’s hard to overstate just how motivating it is to watch your word count climb into the thousands and tens of thousands of words over the course of days, weeks, and months, but there were many instances where knowing that I had made substantial progress up to that point and not wanting to break my streak of successfully achieving my daily and weekly goals was all that kept me moving forward on a particular book.

I don’t know what you’re logging system will look like for the goals that you set yourself. It’s very likely that you’ll have to be more creative than what I was required to do with my writing, but I can attest to the fact that putting in the effort of finding a way to log your progress is more than worth the investment.

With writing, my absolute favorite part of the experience would generally happen around the two thirds or three quarters of the way to completion mark. I generally went into each book with a rough idea of where I wanted things to go, and a set of characters that I thought were interesting, but somewhere towards the last part of the book it seemed like things almost took on a life of their own.

I would go from forcing myself to sit down and write and often quitting as soon as I hit my daily goal, to rushing to my computer every chance I got because I was so excited to see what was going to happen next and how my characters were going to get to the end of the story as it had evolved. It was always a very rewarding experience, and as much as I always wished that writing a book was like that from the very first word, it never was. It was always those daily and weekly habits that helped get me to the point where the writing experience became so rewarding.

I don’t know if you’ll have an exactly similar experience with whatever it is that you set out to do, but so far it seems that every worthwhile task I’ve undertaken has some flavor of that feeling of satisfaction that makes all, or at least most, of the sacrifice worthwhile.

Next year is going to arrive whether you want it to or not, and few of us can devote 12 hours a day to a passion or a new skill, but it’s amazing how even a small investment in time reaps large rewards if you maintain the effort for long enough.

This is becoming a bit of a trend, but now that I’ve got started talking about this subject I have had a few additional thoughts that I think are worth adding to the mix. Unfortunately, I’m once again over my word count for this post and the rest of what I want to say will have to wait until next week.

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.