How Do You Balance Working on Multiple Projects at the Same Time?

As your business expanding and your roster of clients grows (and grows and grows), one of the biggest challenges you’ll face is managing multiple projects. You’ll have so many balls in the air that you’ll run the risk of dropping one of them, which would be a disaster for your company.

So how do you stay on top of everything? How do you make sure that deadlines are hit? How do you ensure that you’re producing quality work? How do you avoid burnout? As with so many things in software development, it really comes down to three key factors: project management, time management, and resource management.

Project Management

One of the key factors to managing multiple projects is having a solid project management methodology with good tools and procedures.

Foremost in having a good project management system is having regularly scheduled reviews of the current development landscape. We encourage folks to do this once a week. During the weekly review, you talk about what got accomplished in the previous week, what’s going to get accomplished in the upcoming week, and what (if any) blockers you have. Each one-week period is called an “iteration” (a term from Agile).

Assigning work for the upcoming iteration is more of an art than a science. A lot of it comes down to estimation and figuring out how long various tasks are actually going to take. It’s generally better to undercommit than overcommit because if you finish early, you can always pull something else from the backlog. (The backlog, by the way, is where all future tasks are stored.)

Once work is assigned out, all you have to do at that point is track progress to make sure that everything is on track to be launched on time. At Gunner Technology, we base a lot of our project management around a web-based piece of software called Redmine, which is a tool that provides the ability to track and manage tasks. You can add all of the users from your organizations, create one-week iterations, and assign tasks to those iterations.

Once all of the work is assigned, then comes the hard part: actually doing the work.

Time Management

Another key factor in managing multiple projects at the same time is managing your time well. Improving your time management skills is largely the result of practical experience. Most people have to figure out what works for them. (And it doesn’t really matter how you manage your time so long as what you do allows you to get your work done on time with the necessary level of quality.)

That being said, there are certain things we’ve found to be highly successful for optimal time management. One great thing to do is to batch up your work. We often talk about getting in the zone (which is akin to Mihaly Csikszentmihalyi’s idea of “flow”) where you’re working on a piece of software and your mind is fully focused on the task at hand and the code is flying out of your fingers.

What often makes getting in the zone tough is being interrupted by constant distractions, which you have to try and control as much as you can. But another mistake we see people make is switching tasks too frequently. If you’re working on five projects, Monday-to-Friday, it’s better to spend 10 hours a day on an individual project than 2 hours per day on each one, each day. You need to focus on one task wholeheartedly (or wholemindedly).

Even better, however, is to split days, working on two projects a day for five hours, which often have the added benefit of finishing your work for the iteration early. This has two noticeable benefits: first, when you inevitably come up against something that is going to take way longer than you imagined, you’ll have extra time to handle that; and second, if you have a bunch of free hours at the end of the iteration, you can always pull something out of the backlog and get ahead.

One other trick that helps you get in the zone is somewhat counterintuitive, but it’s actually something that creative types have used for ages. (Hemingway, for instance, would use this trick and stop writing right when he knew what would happen next so the next day he could dive write in with the next chunk of writing.) But at the end of the day, while you’re still in the zone, force yourself to stop working. When you pick it up the next day, you’ll know exactly where you were going next and you can hit the ground running.

Resource Management

In addition to having a project management philosophy as a company and a time management philosophy as an individual, you also need a resource management philosophy as a team to ensure that people are comfortable hopping in wherever they’re needed.

And, again, this all comes down to standards.

One key step is to document and automate as much of the process as you can. When we build React Native applications, for example, we have a new project script that generates the scaffolding for the project in the exact same way every time. And then we organize the React Native directories the same way for every single project.

(As an aside, in contrast to frameworks like Ruby on Rails or even Angular, which are called “opinionated”, React Native is an unopinionated framework, which means that it’s up to the developer how they want to structure it. Anything can go anywhere – it’s entirely up to the dev. But we’re suckers for opinionated programming at Gunner Technology, so we’ve standardized React Native development as much as we can.)

And there are numerous other standardized processes you can implement. Standardized naming schemes help a ton. Trying to use what are called immutable functions also helps anyone jump into a codebase. (Immutable functions are functions that return the same thing every time given a particular input. There are no surprises!) Even just standardizing tools used can help the process. At Gunner Technology, we use the same devices, the same editors, the AWS tools, everything. And what that accomplishes is that all of our amazing employees can move wherever they’re needed.

So at the weekly planning meeting, using our project management methodologies, we assign work to individuals, who use their own time management systems to estimate their availability. We assign work based on that availability and based what needs to get built that week. And anyone can work on anything thanks to our huge (and ever-growing) suite of standards and practices.

And that is how you balance working on multiple projects at the same time.



What’s the Difference Between a Webmaster, Software Engineer, Software Developer, etc?

These days the lines are getting blurred. Division of labor is somewhat collapsing and web/software developers are increasingly being expected to know how to do just about everything.

That wasn’t always the case, however. In the past there was a more clear delineation between roles, and some of those legacy titles still apply. Let’s take a look at some of the more popular ones.


Just like the name implies, designers are in charge of the look and feel of your site or application. They design the appearance.

Now the actual kind of design that designers do can vary by individual.

Some designers are in charge of the graphical side of the product. They’ll be the ones who create logos and icons. They’ll take pictures and videos to use in marketing materials. From background images to buttons, they’ll be providing the actual assets. Often these people are referred to as graphic designers.

And then there are some designers who will be in charge of building out the actual interface of your app. These folks are generally called UI/UX designers or developers. They’re more concerned with the actual layout of the site. If you think of newspapers as an analogy, the graphics department would provide the pictures for the article, but the UI/UX developers would figure out how those pictures should be displayed along with the text.

Graphic designers and UI/UX developers often work very closely. The UI folks will lay out the page and figure out exactly where they need custom icons or logos or images. And then the graphics department will provide those assets.

Oftentimes, nowadays, the UI/UX developers will have a knowledge of HTML and CSS and will be able to lay the page out using these tools. Sometimes, however, they will simply provide a PSD file or something similar for the developers to go off of when creating the site or application.


When you think about how an actual website gets served, all of the machinery that comes into play, you’re starting to enter the realm of engineers. They might be called software architects, database engineers, SysOps (systems operator), or any number of other titles.

What these folks do is actual manage the hardware that runs your software. They’re in charge of the servers that deliver web pages or API results. They’re in charge of the databases that store and deliver your data. They’re in charge of email and monitoring and logs and remote access and anything that has to do with the actual machines that your application is running on.

They’re providing the hardware for the software, basically.

In recent years, with the rise of third-party, cloud-based solution providers, the role of Engineer has started to come under fire. Engineers are largely becoming obsolete due to the power of automation and outsourced expertise. What would have once required a team of 100, AWS can now provide (with better performance and more stability) for a fraction of the cost, requiring only a handful of engineers to manage.

It’s a nervous time for Engineers.

But the future isn’t all bleak. There is an opportunity with a service like AWS to become an expert at using it and then market your services to companies and individuals. So while the AWS team is focused on the stuff that Engineers used to deal with – uptime, optimizations, etc – now Engineers can focus on rapidly building robust solutions using a third-party service.


In between Designers and Engineers are Developers. Whether they’re called Software Developers, Web Developers, App Developers, Software Engineers, or any number of other titles, their purpose is to be the middleman between the Designers and Engineers. They take the interface from the Designer, convert it to functional software, and then work with the Engineers to come up with a hardware solution for that software.

And one thing that makes being a Developer kind of cool versus being a full-time Designer or Engineer is that your day-to-day is always pretty fresh. Some days you might be digging into low-level CSS to figure out how to make a page display a certain way. Other days you might be digging into low-level MySQL to figure out how to most effectively cache a query. Everyday presents unique challenges.

But Developers are the key cog in the process of building working software. They’re often the ones who convert designs into actual HTML and CSS. They’re often the ones who direct Engineers in what architecture to build out. And in that sense, they’ve always sort of need to be jacks of all trades, with knowledge about every piece of the process.

Perhaps because of that, what’s happened recently is that Developers are largely become self-contained with the ability to complete the entire process from design to development to engineering. With JavaScript packages like React, the lines between Designer and Developer are all but completely blurred. And with third-party services like AWS, the lines between Developer and Engineer have all but disappeared.

At this point, it looks like the future is going to be a Developer’s world. Anyone looking to get into software development should keep that in mind.




Would You Rather Have Specialization or Jack of all Trades?

These are strange times in the world of software development. The technologies available to the world are more robust now than they’ve ever been and even lone wolf individuals can build some pretty incredible products. But the question still has to be raised – is it better to specialize in one thing or to try and become a slightly less knowledgeable expert in a number of different things?

The Specialist

In the world of technology, there are any number of things to specialize in. You could be the world’s foremost expert on optimally creating Block Range Indexes for PostgreSQL, for example. Or maybe you know more than anyone else about installing Redhat linux kernel 3.10.229. And in the past, it was much easier to succeed having that kind of fine-grained knowledge, but the changing landscape of technology is making it much more difficult.

The story of technology is largely the story of automation. From the very first automated looms, machines have sought to supplant physical human labor. What’s really changed in the last couple decades is that our technology is now supplanting our mental human labor, and this has proved to be a harsh reality for specialized experts.

Because the reality of the situation is that nowadays if you can automate a solution based off of one person’s expertise, you don’t need a hundred or a thousand people who know a ton about one particular subject. You just need that one expert who knows the most.

And largely what companies like AWS are doing is scooping up these experts and focusing them on the various bits of minutiae that will optimize their stack. They have teams of people who are working everyday to make their service as powerful and stable as it can possibly be, but those teams of people are able to build a product that millions of people can use. And that’s tough for specializers.

If we imagine a million companies use AWS and that each of those companies would need on average, say, ten specialists working to optimize their product, that’s ten million jobs right there. But if AWS can hire a thousand specialists and those people can create an automated solution that will be just as good? Well, now you can see why it’s not a great time to be a specialist.

(And in reality, the solutions AWS provide out of the box are going to be better than just about anything a dedicated specialist can provide.)

That being said, there are obviously opportunities out there if you truly want to go the specialist route. Clearly AWS is always looking to hire the best and brightest to come on board and make their product even better. And if you really are hooked by something and you want to become the best in the world at just that one thing, more power to you! The world needs specialists. It’s just that the world doesn’t need as many of them now.

The Jack of all Trades

It’ll be no surprise that we’re long on jacks of all trades and short on specialists. The reason being is that the technology landscape as it stands today is being built for non-specialists, meaning folks who want to be involved in every step of the process. Whether it’s new frameworks or third-party services, you don’t need to be an expert in just one thing anymore.

Most developers these days have their hands in every piece of the software development process. They do design (or help do it). They build architectures (or help build them). And then they also write the actual code that powers the application.

And that’s something we encourage at Gunner Technology not only because it really does seem to be the future of software development, but because it’s actually just a lot of fun. Once you have a complete knowledge of the software development stack, the world is your oyster. You can basically write your ticket at that point.

You make yourself so much more attractive to potential employers by being able to hop in anywhere you’re needed, from design through engineering. That’s something any development shop is looking for (and honestly expecting at this point). So it’s somewhat of a necessity to be a jack of all trades these days.

And it’s easier than ever to be a jack of all trades thanks to abundance of technological solutions out there. Stuff like React Native lets you build mobile apps using technologies you already know like JavaScript, HTML, and CSS (although the HTML and CSS look slightly different than what you’re used to). And services like AWS let you launch these apps for pennies on the dollar. You could build a new app everyday with the tools that are out there now.

Of course, a word of appreciation for the specialists. Without them, none of the tools for ths jacks of all trades would exist. Much like theoretical physicists providing the math so that practical physicists can launch satellites into orbit, the software development world needs specialists.

We need the obsessed individuals who want 99.9999999999% uptime for the servers and who want to squeeze every nanosecond they possibly can out of each database transaction. These are the folks who really make it all work, so thank goodness they do what they do.

But if nothing has grabbed your attention in that way, nothing has made you want to do one thing and only one thing for the rest of your career, we can’t recommend becoming a jack of all trades highly enough. It’s the best way to future-proof yourself in this ever-changing technological landscape. (Although, how future-proof that actually is… only time will tell.)



What is the Most Frustrating Thing About Your Job?

Being a software developer isn’t easy. But nothing rewarding ever is. Still, it’s good to know what frustrations lie ahead as you imagine a career in software development.

Platform Discrepancies & Replicating Issues

One of the biggest frustrations you’ll face when working as a software developer is dealing with the sheer number of different platforms you have to develop for.

You’ve got iOS and Android.

You’ve got four major browsers.

Not to mention, you’ve got innumerable different versions of each of those half dozen platforms.

It’s a nightmare!

But it has gotten better.

Gone are the days of having to develop for Internet Explorer 6, the single biggest headache for software developers for the better part of a decade.

And there are lots of tools, like React Native, that help you develop effectively for both mobile operating systems simultaneously.

But there are still tremendous hurdles to overcome to make sure that your application works identically across all of the different platforms.

One of the major hurdles is simply being able to replicate behavior that users are seeing.

If someone is having trouble with a Samsung Galaxy 7 running Android version 7.1.2, odds are you don’t have that specific device or even access to it.

(Again, there are tools, like Browserstack or XCode or the Android Emulator, to help you try to replicate those devices from your machine, but they’re never perfect.)

The only viable solution to try and solve these issues is to have the user record video of their screen to show you exactly what they’re doing and exactly what’s happening. Then it comes down to reasoning about the issue and trying to figure out what might be happening, without being able to actually test it natively on the device.

That can get pretty frustrating.

QA & Testing

Testing is hard. There’s no two ways about it.

First, when you’re developing an app, you inevitably become an expert at using the app just by the very act of building it.

So it can be extremely challenging to get into the mindset of a user. When you actually see people use your app, you’ll constantly be wondering, “Why are they doing that? Why aren’t they doing this?” But you are not your user. The problem is with your interface, not with them.

So you have to involve other people in the testing process, but therein lies another frustration.

People aren’t naturally good at testing.

Often the feedback you get isn’t what you’re looking for. One of the biggest problems here is what we call “pixel pushing”. You’ll get feedback like “this section should be moved up” or “this should be a different color” when what you wanted is for them to test out whether a certain piece of functionality works.

There are ways around this.

One important thing is to have a definite script for testing so you can tell the folks testing your app to follow explicit steps and to give feedback on just those steps.

Another thing to do is to be explicit about what kind of feedback you’re looking for. Divide your testing up into three phases: functional, enhancements, and feature requests. For functional, testers should answer “Does it work?” For enhancements, testers should answer “How could it work better?” For feature requests, testers should answer “What else should it do?”

Unknown Unknowns

With software development, you’ll be constantly faced with novel requests. The trouble is, folks will want estimations on how long those novel requests will take, but by the very nature of their novelty, you won’t be able to give a good estimation.

As an analogy, consider the moon landing. Kennedy wanted to land on the moon within a decade. NASA said it was probably possible. It turns out that it was (and it turns out their estimate was incredibly accurate – maybe a case of self-fulfilling prophecy?) But nobody had any idea whether it would take a couple years or a couple decades.

You’ll have hunches about how long something will take just based off of how long similar requests have taken in the past.

But the details matter.

The more detailed you can get about the request, the more accurate you can be with your prediction. Details provide limits, and limits make it easier to estimate what the actual scope of the request is.

Speaking of scope.

Scope Creep

Scope creep is when the initial set of requests starts to be overwhelmed by a slew of new, incoming requests.

You start with an idea of a project (and how long it will take and what it will cost) and all of a sudden, a couple months later, the project has morphed into something else with no end in sight.

We’ve seen it happen over and over (and over and over) again.

And it’s hard to not let scope creep happen, because there’s really no good answer when a request comes in after work has started for additional functionality.

You can say yes, and then you’re doing work for free and giving away hours of your time.

Or you can say no, and anger your client who will frustrated you can’t just add in some new feature.

So scope creep is almost an inevitability.

But with that in mind, the best band-aid for scope creep is to simply budget for it, both in terms of time and cost. You know that the project is going to extend beyond what’s initially asked for. It’s going to happen. So make sure you have enough time and money to accomplish the unavoidable scope creep.

What Are the Best and Worst Things About Being a Software Developer?

At Gunner Technology, we think software development is the best. But that doesn’t mean there isn’t a whole lot of “worst” when it comes to being a software developer.

BEST: Instant Gratification

One of the best things about software development is that you can see a finished product almost instantly and people can start using it right away.

It’s not like building a cathedral where it might take a hundred years. Or even like building a house where it might take six months. You can start a project in the morning and have it ready by dinnertime for people to try out, which is pretty incredible.

BEST: Refactoring Old Code

You might think going back and looking at old code that you’re written would be a chore.

(You might even think it would be an embarrassing nightmare seeing how bad the code you used to write is.)

But one of the best things you get to do as a software developer is to refactor your code.

Because you get to see just how far you’ve come and how much you’ve learned in the time that’s passed since you initially wrote that code.

When refactoring old code and realizing that you’ve internalized new, better ways of doing certain things, you’ll start to appreciate just how much you’ve learned.

It’s tangible growth, and it’s incredibly motivating.

And it keeps you going long-term, because stuff that would have taken days to figure out will now only take you a matter of hours. That frees up a lot of time to learn even more, and the cycle continues on.

BEST: Working from Anywhere

One of the best aspects of software development is you only need a laptop and an internet connection.

Grab your MacBook Air and tether it to your iPhone and all of a sudden you can work from anywhere on the planet with a data connection.

It’s honestly one of the greatest things about being a software developer.

There are going to be days when you don’t want to go into an office. You’d much rather work from home. As a software developer, you have that luxury (assuming your company allows it).

You can work from a sports bar. You can work at a music festival. You can work on the beach. You can work practically anywhere in the world.

That’s a huge luxury.

BEST: Messing Around with Technologies

If you’re a sucker for novelty like us, this is a huge plus.

As more and more expertise is outsourced to third parties, a la AWS handling pretty much every level of SysAdmin responsibilities for you, you then get to spend that freed up time investigating new tools and technologies to use to improve your day-to-day workflow.

Instead of worrying about setting up and managing your own servers, you get to offload that responsibility onto someone else and leverage their wealth of expertise. (They’re going to do it better than you ever could because that is all they do – they spend all their time thinking about it.)

So you get to experiment with different frameworks, for example, or try out different programming languages.

There’s a ton of time devoted to just trying stuff out and figuring out what the best solution is.

But that’s not all sunshine and roses, as it turns out.

WORST: Messing Around with Technologies

There is a well known paradox with choice. As the number of choices increases, the anxiety faced while making that choice also increases.

(This was highlighted by psychologist Barry Schwartz in his book The Paradox of Choice.)

So there is, in fact, a paralyzing effect when faced with dozens of technology choices.

All too often, software developers have a dozen (or two or three dozen) options to go with when deciding what technology to use for a given project.

It’s easy to get overwhelmed by that.

The best solution is to take a meta approach and come up with a list of attributes that a given technology has to meet. Then simply grade your options, choose a couple of the best, write some code with them, and see which one your prefer.

There’s probably no wrong option (unless you’re choosing a technology that has a realistic chance of disappearing in the near future), so you might as well pick something and go with it.

Better to do that than to freeze up in order to avoid making a decision.

WORST: Flame Wars

One thing that adds to the struggle to choose a technology is the lack of objective opinions about different options.

Not only are there no objective opinions, but there are subjective opinions about technologies held with a religious fervor.

Good luck having a calm, rational discussion about technology options.

If you want to know whether MySQL or PostgreSQL is better, be prepared to hear that MySQL is a “steaming pile of garbage” or that PostgreSQL is for “complete idiots who should probably be flipping burgers instead of writing code”.

That’s the level of discourse you get when talking about technology.

So, again, you’re sort of on your own when it comes to making a decision. Choose a couple really good options, try stuff out, and pick the one that seems to work best. That’s all you can do.

WORST: Software Development Purists

One major headache you’ll deal with with software development is so-called “purists” who feel that there is only right way to do things and that anything that doesn’t do it their way needs to be fixed.

They’re sort of the Spanish Inquisition of the software development world and they’re frustratingly abundant.

And the worst part is, they prioritize correctness (as they define it) over stability.

They will happily make sweeping changes to an open-source codebase that you’re using that completely breaks your application in order to have the code meet their absurd standards of perfectionist quality.

They don’t care about your code. They only care about their (insane) ideals.

And it’s not just code.

So many software developers who use particular project management methodologies follow those methodologies to the letter even when certain practices are inefficient or don’t actually work in their particular situation.

They take the sets of rules as gospel and follow along with them unquestioningly.

You can’t say, “I know it says to do this, but we’ve seen no tangible benefit from doing it and it takes up fifteen minutes every single day.” That’s blasphemy!

They’re purists through and through, and all that matters is their dogmatic obedience to doing things “the right way”.

WORST: Hardware

Hardware is a nightmare.

First off, there are so many devices out there today. So. Many. Devices.

And as a software developer, you’re expected to support every single one without fail.

It’s an absolute impossible demand, but you’ll face it anytime you build something.

Secondly, your individual hardware is going to frequently break, often at the worst times.

You’ll have a demo in fifteen minutes and your MacBook will hard lock, which means you’ll need to reset the PRAM, which means it won’t boot back up for another half an hour. That kind of thing happens all the time.

(And it’s not really the device’s fault – as much as you’ll use your hardware, of course it’s going to break down, but that doesn’t make it any less infuriating.)

Finally, as a software developer, you’ll be expected to be a pseudo-Geek Squad of one.

Everyone and their mother (and your mother) will ask you to fix their stuff.

If they can’t figure out how to put their cell phone into low battery mode, they’ll come to you.

If their email stops syncing to Outlook for some reason, they’ll come to you.

If their latest Windows update is frozen (which happens approximately 110% of the time), they’ll come to you.

Just prepare yourself to pretend to be a hardware expert, because that’s what everyone will imagine you are.

What’s the Biggest Lesson You’ve Learned in Your Career?

Life is learning. Learning is life.

And one career where you’ll learn a ton is software development.

And not just lessons about how to code, either. You’ll learn a lot of stuff that you can apply to your daily life.

Those are some of the biggest lessons we’ve learned as software developers.

Learning How to Fail

“Fail fast, fail often,” is one of those mantras of Agile software development.

We live that mantra at Gunner Technology.

Let’s take you back to the launch of one of our earliest products, ESPN’s Fan Profiles, the first social network for sports.

The day of our big launch was a Friday. At around 6 PM (Pacific time, we were out in LA), we flipped the switch an took the site live. And it immediately crashed.

So we respun up the servers. And it crashed again.

Over and over, we relaunched the cloud architecture, and over and over the site went down.

This went on for three days.

On Monday morning, after nearly three days with no sleep, one of the devs at a software development firm we were working with found the problem.

A hidden configuration setting had the production application running in development mode.

That means nothing was being cached. That means the entire application was being reloaded every request. That means, basically, that the site was doomed.

It was a failure of epic proportions.

But you know what? It was one of the best things that’s ever happened to us.

When you go through something like that, you learn how to fail. And you learn what failing gracefully means.

You learn that the most important part of failure is growing from the failure.

And I don’t just mean making sure your production site is configured correctly or any number of other technical takeaways.

I mean learning how to persevere. How to handle failure with grace. How to be more proactive and how to keep a level head when stuff inevitably goes awry.

Everyone fails. It’s inevitable. If you can fail better, you’ll be better for it. Software development teaches you that.

Learning How to Take Criticism

Software development also teaches you how to take criticism.

You’re never going to know everything. And, as a corollary, there will always be someone who knows more than you (or at least know more than you about a particular subject).

The field is so broad and varied that you can’t possibly be the foremost expert in everything.

But when you do something wrong (or suboptimally) and are called on it, the one thing you can’t do is shut down. You have to embrace the criticism you receive. That’s how you grow.

Whether it’s writing bad code or using a programming methodology the wrong way, whatever it is, if someone shows you a better way to do something, you should be overjoyed!

The goal of every software developer is to produce the best work they possibly can.

And the more helpful criticism you receive, the better you’ll be at software development.

So not only do you learn how to take criticism, you learn how to seek it out. You want to know where your deficiencies are and where you can improve.

Learn How to Be Aware of Your Mental State


It’s a daily occurrence of software development.

You’ll work on something for hours only to throw it away and start over from scratch.

And you’ll do that half a dozen times before finding the actual solution days after you started.

Software development can be extremely exhausting and mentally taxing. And that’s going to make you unbelievably frustrated from time to time.

When you’re in that mental state, it’s probably best to be left alone.

You shouldn’t be working with clients or interacting with coworkers.

You especially shouldn’t be doing anything that involves calm and repose, like giving friendly feedback to someone.

You’ve got to be constantly aware of what head space you’re in when doing software development, and if you’re in an extremely negative state, you’ve got to realize that.

Learning How to Communicate with Other People

Day-to-day as a software developer, you’re going to be talking with a lot of folks.

Whether it’s in a Reddit subgroup or a Slack channel or hopping on the phone with a client or development partner, communication is key.

And most people are terrible at it.

People frequently take conversations in a negative direction – you’ve got to stay positive!

Clients often give vague, innocuous requirements for development requests – you’ve got to remain calm and ask good questions!

Other team members might be bad at communicating about statuses and timelines – you’ve got to continue to press them for details and hard dates!

But the point is to always remain upbeat and level-headed. (And realize when you can’t do that – see the lesson above.)

Life Lessons

All of these lessons – learning to fail, learning to take criticism, learning to be aware of your mental state, and learning to communicate – translate over directly to your daily life. It’s not just about software development.

It actually makes you a better person.

You fear failure less and try more stuff out in your non-work life.

You don’t bite people’s heads off when they give you feedback. You calmly digest and try to improve yourself.

You don’t lose your cool with people because you’re more consistently aware of your mental state, and you become a better communicator and your interactions with other people improve.

It’s strange to say, but being a software developer does actually improve your life.

It’s all about those life lessons!

What Do You Look for When Hiring a Software Developer?

What Do You Look for When Hiring a Software Developer?

At Gunner Technology, we’re all about the 3 P’s: Problem Solving, Persistence, and Pintelligence.

What does the P in Pintelligence stand for, you ask?

What do you think it stands for?

(Creativity is important too.)

But if you’re looking to become a great candidate for a software development position, you should focus on the 3 P’s.

Problem Solving

Most of software development is about problem solving. You’re going to be given a project and told to figure it out.

Consider the way government contracts work.

As discussed previously on the Gunner Technology Livestream, there are three main types of requests the government makes: RFIs, RFPs, and RFQs.

With RFIs, the government is saying, “Here is a problem – figure out how to ask for a solution.”

With RFPs, the government is saying, “Here is a problem – figure out how to solve it.”

With RFQs, the government is saying, “Here’s the solution we want – figure out how to implement it.”

Do you see how even with government work a lot of the work is figuring stuff out? That’s what software development is: figuring stuff out.

So you need to be an effective problem solver to be an effective software developer.

And you’ve got to know how to break problems down into smaller, manageable sizes.

Because often the project is something like “Build a login page.” But building a login page isn’t just one step.

Often it’s dozens or even hundreds of steps.

So can you effectively turn a base problem into multiple subproblems? And can you then turn those subproblems into multiple sub-subproblems?

That’s part of being an effective problem solver, and thereby an effective software developer.

Of course, once you’re confronted by dozens or hundreds of subproblems or sub-subproblems or (sub^n)-subproblems, there’s one major attribute that lets you dive in and plow through them without giving up.


Call it willpower, call it grit or resilience, call it whatever you want. But what it comes down to is your ability to not give up.

The day-to-day work of a software developer can sometimes be exhausting, frustrating, and mentally taxing. But that doesn’t mean you don’t have to do it.

You’ve simply got to stick with a problem until it’s finished. No excuses.

And oftentimes, that can lead to long days or even all-nighters.

Because the reality of the situation is that estimation is one of the most difficult aspects of software development. (Along with the two hardest things in computer science: cache invalidation, naming, and off-by-one errors.)

You get better at estimating with experience, but even with a wealth of experience the problems are often so different that you’re basically a noob.

At that point you’ve got to do your best to be realistic about how long it will take and then stick with the problem when it inevitably ends up taking two or three or ten times as long as you planned.

But the good thing about persistence is that glorious feeling of accomplishment when the task is finally done. That’s what we live for as software developers. And it feels good, man.


Pintelligence. It’s all about learning. If you love to learn, software development is a great field to go into.

Because learning in software development is a lot like the mail: it never stops.

You’ll be learning new things constantly along with new ways to do old things. Software development is a constantly changing landscape, which is a lot of fun for lifelong learners.

There’s definitely a method to the madness though.

If you were just getting started with software development, a great place to start would be learning the basics of the big 3: HTML, CSS, and JavaScript.

These days you’ve got to have a rock-solid foundation with those three technologies.

But it’s really not that tough to acquire. Grab some books and a couple free weekends and dive in. You can build a bunch of websites locally and view them in your browser without even touching a web server.

Try stuff out, build some neat projects, heck, even ask around to see if anyone has a problem for you to try and solve, do whatever it takes to get absolutely comfortable with HTML, CSS, and JavaScript because you’ll be using them constantly as a software developer.

(As an aside, you’ll probably be using these languages more and more as smartphones move away from the native app model and towards the PWA (Progressive Web Application) model. Currently, mobile device users spend 90% of their time on only three apps, so it doesn’t make sense for companies to invest a ton of money in native technologies that will be used for a couple of minutes (if that) per month.)

The more problems you solve as you’re learning these new technologies, the more tools you have in your toolkit, which helps you become a more effective software developer.

A lot of problems you encounter daily as a software developer are ones you’ve solved before. At that point you can just pull out the right tool for the job and knock the task out.

Of course, you’ll often spend a lot of time solving problems you’ve never encountered before, but that’s where the fun is because you’ll be solving something new and you get to add something new to your toolkit when it’s done.

(There is a problem, on the flipside, with having a stagnant toolkit. A lot of software developers get locked into specific paradigms or ways of doing things and don’t adapt and grow. Don’t fall into this trap!)

Once you’ve got a handle on HTML, CSS, and JavaScript, it’s time to become a modern-day expert.

Learn a JavaScript library, like react, and a native device library, like react-native.

Learn how to use XCode and Android Studio to build iPhone and Android apps, respectively.

Get familiar with a cloud-computing solution like Azure or AWS.

If you become an expert at HTML, CSS, JavaScript with a deep knowledge of react, react-native, XCode, Android Studio, and AWS, for example, you will be a force to be reckoned with.

The software development world will be yours.

You’ll be able to build some amazing apps.

And you’ll end up having a ton of fun!