Handling A Software Developer
Things To Know About Programmers
Posted by Charlie Recksieck
on 2020-07-16
I thought I'd give some tailored advice to different types of people who interact with software engineers in different ways.
Employers:
A resume where a software designer hops from job to job isn't a bad thing. That's completely normal in the industry. It shows that they possess the most important traits for the job: curiosity. Of course, you do want them to stick around your company, so if they've bounced around and also recently have gotten married or have had a child, bingo - that's your person!
Software Users:
What kind of an idiot wrote this program? Probably somebody who wasn't given enough time, instructions. And probably a person who's never done your kind of work before and have no idea what would help you do your job.
Clients:
A software designer is a consultant in disguise. To know how the proposed software is going to be used and fit in with existing processes, any good software engineer will want to understand how you do your job. In asking these questions during the requirement gathering process, those questions actually put a healthy spotlight on how you do things. When your developer asks "What happens in situation X?" and nobody at your company knows the answer, don't let the developer be the cart driving the horse. Let that question force you to make decisions that are best for your business, and then that dictates to the software people what it should do.
When it comes to making a money/time estimate on a project or a set of features, even veteran programmers find it almost impossible to nail it down. The term "computer science" is misleading; when it comes to estimating work, the science part is a little harder and it's sometimes more of an art. To try to get estimates, if there's a range of predicted hours a software company is going to have to "cover their ass" by bidding the project on the very high side ... unless you are in a position of mutual trust and can have an hourly "time and materials" method of billing, which will save money. (For a deeper dive, read my article 2 Hours or 2 Days.
Managers/Supervisors:
When it comes to meetings, I'm a little torn. I personally do think being "in the room" when decisions are being made are actually helpful to the senior programmers on a project. (That said, don't send the whole development team, keep the junior programmers out of your meeting. Chances are that YOU don't even want to be in that meeting ... think of how little THEY want to be in it.) But ultimately, developers think a little like computers - just tell them what the input is, what the output should be and then that's all they need to know. Also, re: meetings, try to schedule their week where they have 4-6 uninterrupted hours for meetings-free development. Maybe have their 2 or 3 regular staff meetings stacked up all on Monday morning then they can build momentum and progress the rest of the week.
A few weeks ago I distilled what I think is truly the only worthwhile management question to employees: "How can I help you do your job better." Full article here
Junior Programmers:
When another programmer is critiquing your code, it's not personal. It really isn't. Code review is part of the process and serves to make everything better.
If you have a code issue that takes forever to debug, you try a bunch of things and things start working, you need to resist the temptation to saying, "All good, everything's fixed." When all of a sudden things go RIGHT out of nowhere, that's actually a problem until you all can figure out what did the trick.
Society:
Programmers are used to dealing with the logic of machines. Machines ALWAYS do exactly and only what they were told to do. Programmers can sometimes be mystified by human error. Be patient if you can.
Also, software developers are a little pessimistic and frequently know-it-alls. Again, not a pleasant trait. Forgive us if you're able.
Office Mates:
Most parts of the software process make programmers unhappy. Requirements gathering is a drag to most, architecture decisions are ok and sometimes educational, the start of code is exciting, debugging and testing is hell, and documentation is the last thing they want to do once a project is finished. The coding part of software development is probably only 30% of the time spent; within that time, the debugging is an emotional rollercoaster. It's 9 parts "What the hell is wrong?" kind of hopelessness and 1 part "Aha, that fixed it; all good." Your developer office mate really isn't that emotionally unstable, despair is just part of the job.
Spouses:
As I said earlier, the time spent banging out code is probably only 30% of the job. But during that 30%, most good software developers are as obsessive as a homicide detective trying to crack a case. Once on the trail, your developer spouse might be burning the midnight oil at their desk well after you've gone to bed. This is not a reflection on your marriage, it's just preoccupation which is an occupational hazard.
A great programmer is picky. Variables need to be named properly ("stringFirstName" instead of "Name1" or "Text1"). Indenting matters. Clear parentheses spacing matters. A type can waste hours of your time. So, if your programming husband is driving you crazy because he can't understand why you don't leave your keys in the exact same space by the door every day, try to remember: It's these anal, annoying attention-to-detail traits that keep him employed.
Dogs:
Your owner / best friend isn't mad at you. He/she is just yelling at the computer. Yes, it doesn't make sense to yell at an inanimate object. But it's part of the job. He/she is not really upset. And you're a good boy/girl ... yes you are!