Settling In at the New Gig

August 12, 2016 at 11:28 pm in Personal, Tech, Work

I’m nearly two months into my new job. For those of you that haven’t heard, I am a Technical Editor at DigitalOcean, a fantastic startup based in New York City. I work with a great team of people, and I help open-source enthusiasts share their knowledge through written tutorials. I’m responsible for taking their submitted tutorials and testing them out, looking for inaccuracies, security problems, or other issues a reader might encounter. As I work through them, I look for continuity problems, voice, tone, and style issues, and I often help them improve their writing skills.

This is an amazing opportunity for me because I get to teach people through writing, since our community site gets a ton of traffic, and I get to be part of an organization that has core values that directly align with mine. I also get to bring my experience in writing, editing, publication, and teaching to this organization.

Best of all, I get to work with some super smart and genuine people. There’s always someone around with a positive thing to say or knowledge to share.  In previous places, I’ve always been fortunate enough to have that on my team, but it’s been rare to see that throughout the organization.

By the way, our team is hiring. Do you have strong system administration experience and love to help people improve their writing? Come work with me.  And if that’s not for you, DigitalOcean has a few other opportunities as well.

This current opportunity isn’t a software development position. But don’t worry…. I’ve found ways to continue doing software development.

1 comment

Moving On…

May 23, 2016 at 12:26 pm in Personal, Teaching, Work

I’ve had an amazing time teaching aspiring software developers. Over the course of the last four years I’ve had the privilege of teaching over 400 students how to use Linux, how to build their first web sites, and how to write their first software applications. I’ve met some truly incredible people and forged some great relationships which I hope continue on for many years. But today I turned in my letter of resignation and am looking forward to what lies ahead. I’ve accepted a job offer that was too amazing to pass up, but more on that later.

I’ve learned so much from this experience. I’ve learned how to teach a diverse group of people. I’ve become more comfortable than ever dealing with politics, time crunches, leadership changes, disgruntled customers, and of course, the fundamentals of computer programming. In order to teach those things well, I had to go back and relearn things myself. I now have big ideas about teaching software development to adults, and I hope to share those thoughts as time permits through various outlets.

I’m leaving behind an incredibly talented and wonderful team. They’re among the best people I’ve ever known and they’re going to continue to do great work. I will miss them. I will miss the students as well. It’s incredibly rewarding to see someone transition from knowing nothing about programming to a professional software developer who can do great things for others and provide for their families. I have so many stories like that and am fortunate to have been a part of that journey for these four years. I am forever thankful for that.

But it’s time for a change. I’ll announce exactly what that change is when the time is right.

In the mean time, I’m still hacking on Codecaster and working on a couple of other projects. And I’ll continue to find ways to help people get better at software development.


The Hogan Formula For Software Estimation

July 26, 2015 at 6:20 pm in Tech, Work

Measuring how long a software project will take is a futile endeavor. Unfortunately, people who hire software developers have a habit of asking for the impossible. Like when they want you to build a Facebook clone in 2 weeks for $200.

So to appease my clients and managers over the years, I developed a formula to somewhat accurately address the “how long will it take” question. And despite it being a bit tounge-in-cheek, it’s startlingly accurate when you sit down and think about it.

Here is the formula:

TimeToComplete = (bestGuess * 2) + 1 --> Shift to the next unit of time.

Here’s an example. Someone comes to me and wants me to build a 5 page web site for them. My immediate thought is that building 5 pages of HTML with a Bootstrap theme should take me about 6 hours. That’s based on my experience as a developer over the years. I know I’ll use a bunch of pre-existing things and I know my way around CSS and HTML.
So if I run that through my formula, here’s what I get:

(6 * 2) + 1 = 13 hours --> Shift to next unit of time = 13 days.

It’ll take 13 days to complete this project, according to this formula. Does that make sense? Let’s look.

Day 1: I meet with the client and gather some specific details about the project. It turns out that the client needs 6 pages, not 5, but one of them is a contact form. I’ll be writing a little PHP. Client insists they have all the copy already written for all the pages, and they have photographs. After the meeting, an emergency for another client comes up and I have to deal with that. I can’t spend any more time today working on this project because I’m burned out.

Day 2: I build a mockup of the homepage in HTML with Bootstrap. I then develop a couple additional options. I put a PDF together and I show it to the client by sending an email. I get no reply.

Day 3: I follow up with the client. No reply.

Day 4: It’s Saturday.

Day 5: It’s Sunday.

Day 6: I call the client, since email isn’t working. The client replies that they like the first mockup idea I sent, and wants to proceed with that. I ask for content for the “About” page. They tell me they’ll have their office person send it over. I build out the pages in the template they chose using mocked up content. Productive day.

Day 7: I push the work up to a staging server so the client can play with it. I still don’t have content. I send the URL to the client. They play with it but tell me it doesn’t work on their machine. I test the site in multiple browsers and everything looks fine I head to the client site to see what the issue is with the site. The site comes up fine. They were confused because the text “Lorem Ipsum” was displayed on the page instead of the text they wanted. I ask again about the copy they were going to send over, and they hand me hand-written notes, saying their office person was out of town this week.

Day 8: I key in the content, because I’m nice. I push up the new site. They send me over some photos which I need to adjust to fit. This takes most of the day, but the site is eventually deployed. I get on the phone and walk them through the contact form. They have changes.

Day 9: I’m unable to work on the site much due to other obligations. But I do fix the contact form and ask them to test it.

Day 10: The site is complete, but I’m waiting on final approval from the client. The person in charge has taken a long weekend.

Day 11: It’s Saturday again. But the client does approve the work, with a couple of minor changes. I state that I can make those changes on Monday and I can make it live on Monday.

Day 12: Sunday again.

Day 13: I work through the changes and get on the phone with the client, who says things look great. I put the site live and they use Dwolla to send over a payment. Done.

Does that sound like a realistic scenario?

The problem I’ve found is that developers only think in terms of code. So when you ask “How long will it take to get something done” they immediately drop into “How long would it take to code up an untested first version of something based on what I’ve done before?” As developers, we have to remember that software is 20% code and 80% people. People need time to think about things, they need time to review, and they need time to recover from mistakes or bad choices. We have to factor in vacations, distractions, and many many other things.

Developers love to be a hero with their estimations. I’ve done this. I’ve said “Oh yea that’ll be easy. I’ll just get that done in 10 minutes. And sure enough, two days later I’m still working on it.

Now, in the only-somewhat-fictional scenario I outlined, the client had all their ducks in a row. They paid on time. I didn’t have to work with the ISP to recover their web site password and login information. I didn’t have to deal with people who nitpicked every pixel of the design. All of those things factor in to how long it takes, and all of those have nothing to do with how fast you can write code.

You will have to provide time-based estimates to people who don’t understand software. Do right by them, and yourself, by doing whatever you can to be as honest as possible. Maybe my formula will help you make a more informed decision. Or maybe it can just be a joke between you and your team. Because when you’re talking about a project that would “only take six months” and you’re on year two.

1 comment

Being A Good Critical Friend

January 25, 2015 at 3:58 pm in Teaching, Tech

I’ve been around software development a long time, and a reoccurring theme is to see this kind of feedback from peers:

I’ll never understand the logic behind [some thing I think is dumb / disagree with strongly].


If you’re not using [some technology I like] you’re doing it wrong.

Or a variant of

You’re using [some programming technique I think is dumb]? Well I write big applications. [that thing you’re doing] doesn’t [scale / work well / work at all].

This is so common it’s part of our vocabulary now. And I think we say these things without even thinking about how negatively they can affect people.

When I started teaching, I found myself having to constantly give feedback, and I had to learn to do it in a way that would improve the skills of the recipient. And I think that’s what people are trying to do with these kinds of comments. We all have experiences that we want to share. But in the world of 140 character tweets, it’s hard to do that. It’s easy to be unintentially snarky in a tweet, pithy in a pull request comment, or terse in an email.

So strive to get the behavior you’re after instead. By being a good critical friend.

Ask questions that provoke. Provide actionable suggestions. For example:

I notice you used [x instead of y]. I like y because [some amazing thing it lets me do.] You should spend a few hours with it; you’ll be amazed!

That one works because you have experience you can draw from. But it’s only valid if you’ve actually used both. Don’t just shoot down something you’ve never used.You’ll look like a fool. Experienced programmers are pretty smart about figuring out if you know what you’re talking about.

There’s also this angle, which is similar, but more focused on negative side affects:

I notice you’re using [x instead of y]. I did that a few times and it bit me hard. I wouldn’t recommend it because [x,y,z].

See, starting with one of those things contributes to the overall goal; you want to convince them to use your idea, your approach, your methodology.

You could even go farther. It’s never a good idea to assume they have the same situation you do, so why not ask?

I noticed you’re [doing x.] I’ve had problems with that in the past, but I’d love to know why it’s working for you.


I’ve never had much luck with [doing x]. What benefits are you getting out of it?

This helps the person fill you in on their situation, if they care to engage in the conversation. It lets them teach you something. And it may help them arrive at a different conclusion by themselves, in a strange form of rubber duck debugging. After all, explaining something is a great way to demonstrate correct understanding of a topic.

The other option is to say nothing. Are they doing something that will destroy the world? Will it make you come in on the weekend to fix it? Or do you just find it irksome? Search yourself for the answers to these questions, and if it really is of no consequence to you or others, let it go. Put your energy into something awesome instead.

We’re all programmers, working in a field that’s so new that nobody really has all the answers. When your convictions or beliefs about something are so strong that you must comment, be a good critical friend to the recipient. They may not choose to listen. But I guarantee you have a much better chance that they will than you do with something that puts them on the defensive or makes them feel stupid. I’ve gotten this wrong in the past. Join with me to be better.

1 comment

MonthOfMusic Retrospective

September 24, 2014 at 12:58 pm in Music, Personal

In August, I embarked on a huge task: I set out to record and release one song a day for an entire month. And I actually did it. The entire playlist is up online.

I thought I'd share some behind-the-scenes facts and some things I learned.

Breaking The Chain Is Devastating

When I write a book, I make sure to set aside time every day. And I keep a little log of the activity. Some people refer to this as a "chain" of activity. If you chart out your progress on a calendar, you see that you've done something 3 days in a row, and you want to get to three days. Then you want to get to 8 days, and so on. It becomes a huge motivation to go forward. The same thing holds true for things you don't want to do, like exercise, or study.

If you break the chain, it's incredibly demotivating and actually quite hard to start up again. I used to run every day, and then some outside events made me break my chain, and I've never been able to get back to an every-day routine.

I had motivation to not break the chain this time though; I was publicly accountable. I shot my mouth off in public about releasing songs every day, and after a little while, people started asking me where the song was if I didn't have it out. There were a couple times when I published the song at 11:30PM, but I didn't miss a day.

I want to get back to running every day, so I'm going to apply what I learned this month to that. I'm going to come up with something that nags the hell out of me every day so it becomes a priority.

Being Forced To Do Something You Love Sucks

I love to write and play music. But there were some days when I really didn't feel like doing anything, and I think those days really show when I listen to the playlist over. There are some days where I'm just really half-assing my way through the writing process or the performing process. A couple songs only took me 15 minutes to do because I just wanted to be done and move on. The fun wasn't there.

I don't think I could do this for a living.

If You Practice, Your Muse Will Come

While I wasn't always happy to do this recording every day, I'm glad I did, because a few of the things I did are some of the best songs I've ever made. And I wouldn't have made those songs if I wasn't writing songs every day.

I think this holds true in other places. If you love to write, or take pictures, or paint, or do anything else creative, make a little time for yourself to do that every day. That inspiration may come out of nowhere.

Noodling Helps!

I have a tiny 25-key Korg Nanokey sitting on my desk and my software is almost always running in the background. When I'm working on a lesson plan or writing some code, I occasionally get stumped on a thought and start playing something on the keyboard just to focus my mind somewhere else.

This process produced several melodies that ended up in songs.

Nobody's Listening

Well, not nobody, but based on the statistics, despite doing this for 31 days, I have a really low listen count, and almost all of the listens are repeat listens from the same core group of people: friends and family.

It's incredibly hard to promote yourself. One of the lessons I learned this month was how useless social media really is if you're just an individual. The average person has too many things going on in their stream, and unless you happen to post when they're looking, they're not going to see your stuff in the stream of information.

And if you post too often, people tune out because they don't want to see repeats. Twitter even stops you from posting the same tweet twice.

But this goes hand in hand with the idea of self-publishing. Many aspiring authors believe they can just make it on their own, without a publisher. But in my observations, that's just as likely as me starting something that overtakes Facebook the way Facebook overtook Twitter. It's a remote possibility, but not likely. Sure, you can find successful self-published authors. But for every successful one, there are thousands of unknown ones out there. Just look at Leanpub.

The Internet gives us the freedom to publish things. Anyone can get their ideas out there for the world to see. But getting people to pay attention is an uphill battle.

Based on this, I have a much better picture of what it takes to do real promotion on the Internet.

Ship It, Even If It's Not Great

In order to make sure I could make this project a priority, I had to "timebox" my music sessions. I gave myself an hour a day, and I vowed to ship whatever came out of that session. Most of the time I just didn't have any more than an hour to spare.

A couple of the songs I did are really rough as a result. But they're out there and I got feedback on them from people. And now I can refine them and either remix or re-record them.

If nobody sees it, nobody can tell you it's great.

What's Next?

I'm looking forward to doing the 2015 RPM Challenge this year. I'll have a month to produce an album, and I already have an idea of what it's going to contain.

I'm also planning to take a few of my favorite songs from this project, polish them up, and put them up for sale in a few places, just to see what happens. So stay tuned for that.

But most of all, I'm taking what I learned from this and putting it to good use.

So now it's your turn. Produce something every day for a month. Let's see the results of your creative endeavors! I'll bet it'll be amazing.

1 comment