10 Tips for Working with Software Developers

I’ve spent the last few years working with software developers. Here’s a few tips I picked up along the way.

I started working at a tech company 5 years ago by accident. I didn’t know what an API was. I didn’t know anything about agile methodologies. I didn’t know what a spec was. I’d never heard of GitHub or Pivotal Tracker.

I knew nothing and it was perfect in a lot of ways because I didn’t have any bad habits or opinions.

I somehow landed a job at a start-up sports app where I was in charge of providing content and interacting with the community of users playing the app.

I did that for my first 8 months at the company but things can change quickly at a start-up. Certain needs presented themselves and I moved from content to quality assurance. About two years later, I moved again from quality assurance to project management.

I recently left that job, but during my time there I worked on various web and mobile projects with iOS, Android, and Ruby On Rails developers where I made pretty much every mistake you can imagine.

But I also learned a hell of a lot about software development and the people who bring it to life.

So anyway, enough about me. Here’s what I learned:

1. Nothing is impossible but everything comes with a cost

Some things are pretty damn close to impossible, but when it comes to software development almost anything can be done.

But that statement comes with a caveat: nothing is impossible, it just might take more time than you have, cost more money than you can afford, or require more developers than you currently have staffed. In all likelihood, it’s some combination of the three.

As Kevin Garnett said:

Of course, for anything to be possible, the Celtics had to get 3 Hall of Famers on the same roster and surround them with a good supporting cast while contending with the salary cap.

Similarly, achieving lofty goals in software can be done, but it won’t happen overnight and you might need to spend more money than you thought.

It’s not that something can’t be done; it’s just that some things aren’t practical.

2. Don’t ask developers why software is buggy

That’s like asking a writer why typos exist.

That’s like asking Peyton Manning why he throws interceptions.

That’s like asking Stephen Curry why he occasionally misses open shots.

Nothing and no one is perfect. Software developers are no exception.

3. Software developers are smarter than you

I suppose you could have an IQ of 147 but if you have an IQ of 147 I hope you’re not wasting your time reading this. I hope you’re out somewhere saving the world.

In all likelihood the software developers you work with are smarter than you. And that’s ok.

Don’t let it affect your ego or how you do your job. Just come to terms with it and move on. You may have finished at the top of your class your whole life but when it comes to the world of software, you’re on their playing field and they’re the experts.

4. Respect the people who are building the software

Software developers are not robots. They do not sit by their computers and wait for your commands.

Though their job may often consist of people asking them to do things, it doesn’t mean they enjoy when people bark orders at them.

Besides the fact that you should treat everyone with respect no matter who they are, you should be really nice to the developers you work with. You shouldn’t just be respectful because their skillset is incredibly in demand or because a good developer is worth their weight in gold.

You should be respectful because what they are able to accomplish is really and truly awesome.

Some of the most interesting and enlightening people I’ve had a chance to work with during my life have been software developers. If you respect them it will make your life easier, it will make their life easier, and you might even learn a few things.

5. Listen to the developers you work with

The developers you work with know the ins and outs of the platform they’ve built and they know when something is extremely difficult to do. Whether or not that determines how you proceed is up for debate, but it’s necessary for everyone to be on the same page.

You can try fighting for what you want, and you might win, but even the most informed non-technical people are probably only seeing 10–15% of the landscape about why something should or should not be done from a technical standpoint.

Invariably, business needs will intersect with the technical side of things and may dictate certain courses of action. That’s a fact of life. But be sure you’re flexible and talking with the developers before you promise the world.

Remember: the developers are the ones who ultimately make those promises come to life. They better be on board with whatever it is that’s being promised.

6. A five-minute conversation can save weeks of heartache down the road

Don’t assume anything is easy to do. Don’t assume that because a previous project worked a certain way the next one will follow suit.

Communication is your friend.

I can’t tell you how many times a five minute conversation could have avoided huge problems and made everyone’s life easier.

So yes, communication is good. But it’s more than just communicating.

You need to be communicating 100% of whatever it is you’re discussing. Don’t communicate 80% and assume that the other 20% is implied or that the other 20% isn’t a big deal. I’ve been amazed at how something I thought was simple or implied isn’t simple and wasn’t implied.

As Cosmo Kramer said, “Assume? Never assume anything!”

7. Estimates are an inexact science, and things will take longer if the specs change halfway through the project

For obvious reasons, one of the first things that software developers are asked to do at the start of a new project is estimate how long it will take to complete.

But if the project deliverables and specifications aren’t set, it can be nearly impossible to give an accurate estimate.

In cases where the proper information is available, keep in mind that complications always arise. Estimates are called estimates for a reason. It’s a best guess at how long things will take given what is known right now.

But if the project specifications change six weeks later, you can bet that the estimate will change as well.

Making changes to what the developers are building halfway through a project is like telling an artist you want them to paint an apple and then when they’re halfway done with painting the apple you change your mind and ask them to paint a BigMac instead.

They’re both paintings of food, right? What’s the big deal?

Wrong. It’s a very big deal.

Things happen. There are miscommunications. People change their minds. People make mistakes. But expecting that changes to the project will not affect timelines is naïve and a great way to piss off developers.

8. If you can get developers excited about a project, do it

I hope this doesn’t come as a shock to anyone, but here goes:

developers will be more interested in writing code when they are excited about what they’re working on.

As far as I’ve been able to surmise, writing code is no different than any other job in the sense that if you’re motivated, you will generally do better work.

At the risk of sounding like a broken record; the developers you work with are not robots. It’s a lot different for them to do mindless busywork than it is for them to work on something challenging and interesting.

The nature of what they’re working on and the overall team morale surrounding a project can make a huge difference. You may be surprised at how quickly things get done when people are actually excited to work on something.

(One quick note on this point: if a project isn’t exciting don’t try to put lipstick on a pig. Go back to #3. Software developers will be able to see right through an insincere attempt to rally the team behind something that no one really cares about)

9. Software development is not magic

When you’re using the perfect app or browsing a beautifully designed website it really feels like magic.

But for every app or website that feels like magic there’s thousands of lines of code that were written by a human. It’s easy to see the finished product and assume the software developers are magical wizards who simply snap their fingers and beautiful, functional things just appear. But get real.

The first few builds of an app or website will be rough. It will take time. There will be bugs. There will be regressions. And it’s all a part of the process. The finished product may feel like magic, but everything up until that point almost certainly will not.

10. Enjoy how awesome it is that ideas sketched out on paper and abstract concepts actually become apps and websites

By the time the product launches everyone is probably exhausted and it might be a small miracle that all the people involved can still be in the same room. But in spite of how difficult things were during the development process, don’t forget to take a step back and appreciate what was built.

The fact that a bunch of ideas and sketches are now something you can touch and carry around in your pocket is a small miracle. Enjoy it and enjoy that you work with great developers who played a big part in making it possible.