As a manager or marketer working with developers, getting the best out of your programmers is a delicate balancing act of understanding what matters to them the most and doing part to ensure they have what they need to succeed. However, knowing what to expect from a developer’s workflow can be hard if you are not a programmer yourself.
Here are 8 common things non-coders don’t understand about coding:
- Do not manage coders on a whim.
- Trust the developers to do their jobs.
- Programmers need insight into the project’s overall goals.
- Coding relies on detailed project requirements.
- Coders prefer to avoid non-development tasks.
- Coders need managers to listen and provide feedback.
- You should get to know your developer as a person.
- Switching tasks mid-stream is disruptive.
Let’s look at the things non-programmers do not understand about coding and what they need to do to reduce the friction they might create with software development professionals or teams. As a non-coder, this article will help you understand what developers wish you knew!
Table of Contents
1. Do Not Manage Coders on a Whim
A key mistake you should avoid is thinking that programmers can read minds. A second related mistake is assuming that you can randomly throw an idea for a new feature, and the programmers will add it to the app.
To avoid falling into this trap, ensure that you communicate the details of every feature you need clearly, showing how you think the app should work. Afterward, stick to the game plan until you release the first version. It is demoralizing and a waste of time and money to throw out a vague idea, tell your coders to build it, then tell them that the finished application is nothing like what you wanted.
2. Trust the Developers To Do Their Jobs
A common desire of most developers is to have their abilities recognized by a manager who trusts them to get the job done. Let your developers do what they love: writing code. Find ways for developers to do their jobs with minimal disruption.
Do you suspect that your developer is padding their hours or slacking off at the nearby Biergarten? You should trust the expert you hired to do the job. Give your coder the tools to complete their tasks, offer direction, and provide a flexible environment for them to work. Give them sufficient authority and breathing room.
When you give your developers the time and opportunity to think outside the box and develop their solutions, they stay creative. When they are creating, get out of your coders’ way. You hired them for their expertise; let them prove you right! Coders don’t appreciate being micromanaged, especially by people who are not familiar with coding.
3. Programmers Need Insight Into the Project’s Overall Goals
Streamlining of development practices through methodologies like Agile and DevOps has caused a transformation in coders’ responsibilities in recent years.
Today, programmers do more than just write code as it seemed a decade ago. Back then, the coder’s role was laser-focused on only writing code, releasing it to the world, and moving to the next project.
Things have changed. Coders must create complete applications. The apps need to work for people spanning various geographies and platforms. Your programmers need to have greater insight into your organization’s business objectives, company principles, and customer experience goals.
For their code to work well, you need to offer your coders constant feedback from your management and customers. You need to treat your coder more like a business partner than a code slinger.
4. Coding Relies on Detailed Project Requirements
Programmers can face significant hurdles in delivering their work if you do not provide detailed requirements. Many non-coders who lack development or project management experience try to give a broad overview of what an application or website should look like and hope that their developers share their vision.
Unfortunately, it rarely happens this way. Because your developers rarely have your exact vision for the application, they are unlikely to deliver the results you want unless you provide detailed requirements.
Understanding the state of an application interface in development provides an easy way to understand what you need to do. Every user interface in the app is in one of 4 stages:
- There is no activity.
- There is an error.
- There is activity.
- Action completed successfully.
When you build a new app, you probably only provide your programmers with the specifications for the “success” and “activity” states, forgetting about the others. However, you should understand that your developers have to write the other states when implementing your vision.
To save yourself time and spare coders the aggravation, you should take the time to fully visualize how your application should work, put it down on paper, and go over it in detail with your development team to ensure that everything is clear.
5. Coders Prefer To Avoid Non-Development Tasks
Developing software is highly-skilled knowledge work, which means that developers require plenty of time for what renowned computer scientist Cal Newport refers to as “deep work.” Deep work involves high-value, cognitively-demanding tasks, which means that coders view activities that don’t involve software development as unrelated to their work.
Despite being a staple of the knowledge economy, frequent meetings hold little value for people who write software. As a non-coder, it is important to protect your developers from activities they consider time sinks like administrative paperwork or non-technical meetings.
Creators like software developers, like an entire morning or afternoon, where they can get into the flow and think deeply about the solution to a problem.
Interruptions to handle non-technical chores during this time are extremely damaging. It could take hours for the developer to get back into their flow state after dealing with an interruption.
6. Coders Need Managers To Listen and Provide Feedback
Developers generally don’t expect you to understand what they are doing. However, they want you to listen and respond to what they have to say before making decisions that affect their work.
As a manager or leader, you should take time to chat with your coders to find out what motivates them and get an idea of what they need to complete your project. Wherever possible, you can apply this strategy across the entire organization so that your non-technical team can honestly and openly communicate with your developers.
Another thing that coders appreciate from feedback is specificity. Developers are naturally highly cause-and-effect oriented individuals, which means subtlety isn’t always the best option. Indirect suggestions aren’t always helpful to a coder, since they may not know what you are hinting at.
Additionally, communication involves much more than accurately exchanging information. It also involves verbally giving praise and feedback to your developers to motivate them to continue their good work and strive to be even better.
However, feedback is not always about telling your developers how great they are. It also helps set expectations or point out areas where they could improve. Point out issues fairly and consistently so that your developers take your ideas on board instead of offering resistance.
7. You Should Get To Know Your Developer as a Person
Whenever possible, try to establish a personal connection with your coders. You do not necessarily have to be best friends with your developers, but you need to understand that they are human beings first and coders second. Every coder has their own life and personality outside their work.
Every once in a while, take time to find out how members of your development team are doing. Let them open up to you about anything that’s on their minds. Talk to them about how things are going outside of work.
Getting a deeper understanding of your software developers will allow you to be a more effective leader.
Different people respond in unique ways to different leadership and management tactics. For instance, there could be an individual who works best without direct feedback and another who requires a softer touch. One of your coders may be less available during the afternoons since they have a child they need to pick up from school.
You also have to deal with extroverts, introverts, and every other personality type in-between. According to Scott Stiner, CEO of UM Technologies group, understanding your developers’ personalities allows you to work with them in a way that brings the best out of their unique skill sets.
Getting a sense of your developers will allow you to lead them in a way that will bring out the best in them. However, using the wrong tactic can backfire, causing conflict and lost productivity. That’s why it’s crucial to get this right by knowing your people.
8. Switching Tasks Mid-Stream Is Disruptive
When you have to handle multiple application development projects, you may ask a coder to work on a project in the morning, then switch to another in the afternoon. Although you may feel that simultaneous projects may require your programmers to multi-task, it is detrimental to your project’s progress.
This practice, known as context switching, results in cognitive overload since humans cannot efficiently handle interruptions when they are forced to bounce among several unrelated tasks.
Your coders spend a lot of their attention juggling complex computational and conceptual tasks in their heads. Disrupting their flow comes at a tremendous cost – a single untimely interruption could set your developer back as much as a day.
Your programmers will appreciate it if you have small, distributed groups instead, with dedicated projects that they can fully focus on completing.
Was this article helpful?
Share your thoughts by replying on Twitter of Become A Better Programmer or to personal my Twitter account.
