Thinking Beyond Coding

By Erik Peterson

Are software developers merely coders, or are we something more?

I spent 11 years developing software, and I’m still amazed at all we do. This book is for anyone thinking about a development career or curious about the odd people who choose that path. No coding experience necessary!

In this book I’ll describe developers and share what I’ve learned about the career. Topics include:

"From Here to There": How to get started, the role of college, and the interview process
"Daily Life": The developer's many tasks
"Simplify": A brief look at development history
"People vs. Process": Why corporate processes so often go wrong

• Language: English
• Publisher: Erik Peterson
• Release date: Oct 21, 2014
• ISBN: 9781311264688

Erik Peterson

I'm a software developer turned writer. My first book, Thinking Beyond Coding, came out in October, 2014.

Book preview

Thinking Beyond Coding

Exploring the Development Career

Erik Peterson

Copyright © 2014 by Erik Peterson.  All rights reserved.  This book may not be reproduced in any form without permission of the author except for brief excerpts in published reviews.

Smashwords Edition

To my co-workers, who showed me the developer life.  To my church family, who gives me strength.  To my dad, who blazed my family’s development trail (and saw the ugly drafts of this book).

But most of all to my wife, for supporting me all along the way.

Introduction

You’d think writing code is all we do.  Just look at the bookshelves stuffed with programming books, or peruse the endless programming courses on iTunes U.  The volume’s there for a reason: coding isn’t easy.  But developing software means much more than typing strange-looking words into odd-looking programs.  That’s just a fraction of what we do.

So let’s set aside the coding books and discuss the software development career.  I spent 11 years at a large software company, and this book is my way of explaining our work.  Whether you’re an aspiring developer, a current practitioner, a perplexed manager, or a curious spouse, there’s something here for you.

There’s no getting away from complex concepts, but I promise I’ll stop and explain them.  I’ve bolded some of the ideas we use every day, and all of them are in the glossary.

This book has two parts.  In part one, we’ll talk about developers in broad strokes: who we are, how we’re trained, day-to-day life, and a few of our many tools.  In part two, we’ll look at some specific topics and lessons.  And there’s plenty more at findingaplacebooks.com/thinking-beyond-coding.

About Developer

People who write software go by many names.  Why do I use the term developer?

My company called me a software engineer, but I didn’t engineer in the normal sense.  A civil engineer designs highways, but he doesn’t pour concrete or patch broken roads.  A mechanical engineer designs a car’s structure, but she leaves the welding to others.  Software developers, by contrast, are designers and producers in one.

Calling us coders or programmers makes us look like code-churning machines.  Hacker is even worse.  (A hack is a quick and ugly solution, one without design.)  A software developer takes pains to design, create, and maintain good code.

But developer is a pretty generic term.  What does it mean?  Let’s find out….

Part I: Broad Strokes

1. A Developer Is…

Every artist was first an amateur.

—Ralph Waldo Emerson

Americans love sound bites.  I guess that’s why we see software developers as coders.  That description is quick, easy,…and wrong.  In fact, a developer is…

…A Learner

In Texas we like to say that a weather change is only minutes away (except in summer, when you’ll wait months).  Technology has the same feel: whatever we buy is outdated as soon as we leave the store.

While development is forever in flux, it isn’t quite that bad.  Most of us spend years with a single programming language or development style before moving on.  And we’re not the only ones keeping up with a changing profession.  Doctors must keep up with new medicines and new techniques.  Lawyers have to watch for new laws and new rulings.  Even writers, keepers of one of the oldest skilled professions, must adjust to market and language changes.

So if you think that you’re done training once you leave school, I’m sorry to be the bearer of bad news.  Learning never stops.  In the office, like the classroom, you face new concepts and new problems all the time.  And there’s no teacher like experience.  You can read books, peruse blogs, watch videos, and attend classes all you want, but it won’t be enough.  A doctor doesn’t go into private practice until they’ve had years of…practice.  Lawyers can’t argue a big case until they’ve worked on smaller ones.  No writer makes it big until they write and rewrite.  And no developer understands a technology until he tries it.

A developer must try out and tinker with new ideas on her own.  Technology’s currents carry off the lax; only those that embrace the constant classroom will stay on course.

…A Communicator

What makes a friendship work?  Common interests?  Proximity?  While they help, communication is the glue that bonds people together.  If you aren't talking you'll soon feel a distance—even from your neighbors.

The best software teams become friends.  They help each other and share in each other’s joys and sorrows.  Like any friendship, this doesn’t just happen: it takes communication.

But even teams of friends won’t succeed if they can’t talk to the outside world.  Sometimes a single misstep brings failure, or one great presentation leads to success.  Howard Dean lost his chance at the presidency with one wild speech.  Some companies spook investors with scary messages even as others shoot to the top with perfect pitches.  Unless you can show the world your technical know-how, that know-how won’t take you anywhere.

Developers talk with many different people, including managers, designers, testers, technical writers, the media, and customers.  We work with both the technically inclined and the tech-averse; with those who love detail and with those who want sound bites.  Whether crafting a big presentation or answering a single user's question, we must communicate clearly.

As you can imagine, it’s hard to explain technical details in non-technical language.  Tougher still is explaining without preparation.  I can’t count how many times I confused someone who stopped by with a quick question—because I couldn’t find the right words right away.

In this business you need not be an orator (thankfully), but you must be able to express yourself to people of all backgrounds.

Communicating with Code

Writing code is much like writing words—it’s hard to write something that’s clear and concise.  And while computers will follow your wildest whims, people have no tolerance for confused code.

Just as it takes many years to learn to write sentences, writing clean code takes time.  It’s a lot of little things: logical directory structures, splitting up code in reasonable ways, using good names, and other aids that guide your readers along.

Comments (text that the computer won’t