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.

8 comments

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.

3 comments

Things every web developer should know

March 25, 2013 at 8:44 am in Tech, Work

I believe that web developer should have a command of a few simple things in order to tackle the random craziness that web development entails. This isn’t, by any means, a comprehensive list. It is opinionated, but also based on things I see other people I respect demonstrate in their daily work.

JavaScript

It’s everywhere and you can’t avoid it. You also can’t afford to continue the copy-and-paste approaches of the last 15 years. JavaScript is a major component of modern web applications, and no matter how good your C# or Ruby code is you need to know this language well. And it’s an… interesting language. Don’t let its syntax fool you; some things simply do not work as you’d expect. Learn it well, including proper patterns for creating objects, encapsulating code, and handling large numbers.

PHP

I don’t enjoy PHP, but you really should know it well enough to avoid creating chaos. It’s available on nearly every server out there, and it does fit a certain type of application space very well. I’m not going to write a forum or a blog by hand – I’ll use WordPress or phpBB, and at some point I’ll need to know how to customize the behavior or themes which will require PHP knowledge. Also, creating a simple microsite, API, or even a contact form is a pretty simple task that PHP handles quite well.

Basic knowledge of Vim (or emacs)

No, don’t ditch SublimeText or Visual Studio.  I prefer Vim, but I’m not saying you’re terrible for using something else. Here’s the deal though; Vim is available on every platform, and its chief usefulness is editing text files from the Terminal. Whether you host your web pages on a VPS somewhere or on a shared host, knowing how to use Vim (or again, Emacs) to quickly view
and edit files on the server can get you out of a jam. It’s unwise to edit files in production in realtime without testing code or using version control, but sometimes bad things happen and you absolutely need a fix out there now. I’ve used SSH and Vim while on vacation to fix a corrupted web server configuration file that someone else broke, and I’ve used it to quickly change a very bad typo on a public-facing web page while at the mall. Seriously, look into learning one of thse tools.

Understand Basic SSH, SCP, and Public Key

In order to easily edit files on your server with a text editor like Vim, you’ve got to know how SSH works, and in order to do it securely, you need to understand public key authentication. That’s where you generate a public key and a private key on your computer and then give the public key to the servers in which you want to log in. This extra layer of security is crucial for modern sites.

If you’re using FTP to transfer files, look into SFTP, the secure FTP protocol often available if you’re using SSH. It can also use public key authentication. And if you’re interested in copying multiple files from your machine to your servers, look at SCP, or Secure Copy. It’s a great simple command-line method for moving files around.

$ scp -R public_html username@server:/var/www/html

Honorable Mention: Node.JS

JavaScript runs on the server-side now, thanks to Node.JS, and a lot of developer tools are showing up. For example, testing tools, concatenation and minification tools for CSS and JavaScript, and even tools that reload your browser when you make changes are all written in Node.JS. Tools like Grunt make it easy to create a sophisticated build and test environment for your projects, and if you install Node.JS you can also take advantage of CoffeeScript.

So that’s my basic rundown. As for me, I personally can’t do web development without CoffeeScript or Sass, but those aren’t necessary for everyone to know. Share your thoughts.

1 comment

Another Change of Direction

June 15, 2012 at 3:52 pm in Personal, Work

For as long as I can remember, I’ve had this passion for showing people how to do things. When I was in fourth grade, my dad, a teacher for the blind and visually-impaired, taught me how to program on an old Apple IIe computer. Once I got the hang of it, I started teaching my friends how to do write little programs of their own in our short-lived computer club after school.

When I went to UW-Eau Claire, I got a job in the web development area. Io once again found myself helping students learn how to program. I graduated and got a permanent job there doing all sorts of application development, from ASP to PHP to Rails. And for over eleven years, I’ve been fortunate enough to hire, train, and work with some great people who became amazing software developers, not to mention great friends.

During that time, I’ve also written books and done on-site and remote training sessions.  I’ve helped authors shape their books as a book editor. I’ve even been asked to teach in the classroom at UW-Eau Claire a few times, where I’ve been able to share my love of software development with people just getting into the field.

I love writing code. There’s something pretty cool about solving problems with code, but to me it never quite compared to the feeling I get when I help someone else become a better programmer. And it seems that no matter what I do, I gravitate toward teaching. Now, whenever I am learning something new, I’m thinking “How would I teach this to someone else?”

This week, I accepted a teaching position at Chippewa Valley Technical College. I’ll be part of the IT Programmer/Analyst program, teaching people how to build better software. I’m extremely excited about the opportunity. The program they offer looks great and I’m looking forward to helping even more students become competent developers when I start this fall.

While I’ll be leaving my current day job, I’ll still be hacking on Ruby and JavaScript code, and I’ll still be writing books. But now I’ll get to put more energy into teaching, and I can’t wait to start.

7 comments