I’ve had many managers throughout my career. I’ve seen some thrive, and some get fired. Some were loved by their teams, and some were despised. Some only cared about what time people arrived in the office and at what time they left (it had better be eight hours! Or Else!!!!), instead of the results and value they provided to the team and company. I’ve also been given the chance to manage some teams of my own and made my own mistakes along the way.

My goal of this article is to help new managers (or existing managers) become like the managers that have thrived instead of the ones that have been despised. To help them become LEADERS instead of just managers.

I believe that it boils down to three main rules. As always, there will be other factors that play into people liking you or respecting you (read Dale Carnegie’s “How to Win Friends and Influence People” for more on that), but what I’ve found is that if you concentrate on these main areas, you will be a successful leader and software developers will want to work for you and WITH you.

Rule Number 1: Trust Developers to Do Their Jobs

Some managers act as though developers, left to themselves, would never write a line of code, and instead would spend all day playing computer games. That just isn’t true. The primary wish among developers is that managers recognize their own (and their team’s) abilities, and trust them to get the work done. (“Try and challenge me. I’m so much more than what you use me for,” wrote one anonymous developer via Twitter.)

“All motivation comes from within,” says SQL consultant Jamie Morison, who was a developer for 30 years. “Developers need to be allowed to develop because that’s what they love to do,” he says.

Managers can appeal to the pride a developer feels in his work. “Find out what the developers like to do, and find a way to let them do it so that it benefits the company,” suggests an anonymous software developer at Assurex Health, Inc. “The most motivated people are those who do what they like doing.”

“I want my IT manager to understand that I care about the quality of my work,” says Craig Rinehart, senior application engineer for a consultant firm in Cincinnati, Ohio. “I comment my code with my name, and thus ‘sign’ every script or procedure I write. Nothing frustrates me more than having to do a shoddy job or compromise quality.”

You can’t appeal to developers’ creativity unless you give them the time and space to think and create. Techies need time to think as well as doing the code.

Developers, as a general group, are highly competent individuals. They need to be given room to develop solutions on their own (although perhaps subject to peer reviews to some extent) without being hand-fed work and methodology by management. Nothing quashes the spirit of a good developer quicker than being given a task and then told how he/she must accomplish it. Nor should managers expect software to be cranked out by factory methods. Software development is not a Six Sigma activity. You’re discovering, not producing widgets.

Instead, give developers the big picture. “The more work I am assigned in advance, the better,” wrote one via Twitter. “I can see the endgame on my own instead of having it fed to me by someone else.”

Rule 2: Don’t Give Them Mundane Tasks

Most developers want to focus on creating good code. And just about everything else is irrelevant to them.

To many developers, the manager’s most important role is to protect them from office shenanigans. Developers want and expect their management (including the layers between themselves and the CIO) to take care of all the corporate crap, useless meetings, paperwork and other time sinks.

Other developers complain about managers who remind them about pending and late deadlines several times a day. They resent managers who tell them to serialize their tasks. “Give me a priority queue of tasks and let me get stuff done,” wrote one developer via Twitter. “Get out of my way. I know what I’m doing.” Many developers say they work best with people who give them problems to solve and do not interfere with how the individual solves them.

Rule 3: Listen. Respond. Praise.

Developers don’t necessarily expect that the boss will understand what they’re doing. They do, however, want the boss to listen and respond to her staff before making decisions. Chat with the people who do the work once in a while. See what motivates them, and perhaps even get an idea of what it takes at their level to complete a project. Motivation can start at the top and bottom, but if you never directly communicate, there is no real understanding.

Listen actively, speak openly is an important goal to have as well. Without open and honest communication, you set yourself up for a lot of heartache. Be specific; subtlety is often lost on developers who are very cause-and-effect oriented. “Non-directive” suggestions aren’t helpful, since a developer may not have any idea what you’re hinting at.

Communication doesn’t mean only the accurate exchange of information. It also means giving feedback and praise to developers—especially if you want to motivate them. “Verbal praise works for me,” wrote one anonymous developer via Twitter. “Even if I’m not the best, I still need some positive talk to move me.”

Following these three rules will gain you much respect from your developers. The will love you for trusting them, giving them meaningful work that takes advantage of their skills, and listening and responding to the input that they provide you.

Let me know in the comments if you are a manager and what your reaction to these “rules” are. Do you follow them already? What have your results been?

If you enjoyed this article, then I ask, please share it or like it. It’s important to get the word out there to managers who just don’t seem to have a clue how to manage and utilize some of the most useful and productive people they will ever meet!

Thanks, and follow me at my blog (jasonroell.com) for updates on the wild and fun career that is being a professional software developer! Cheers!

I have worked with a large variety of programmers. Some were what the industry call “junior” developers (beginners) and some were “senior” developers (experts). While working with these people I started to notice that the better programmers (not necessarily the seniors) seemed to understand certain concepts much better than others.

Surprisingly, this knowledge didn’t have a direct correlation with the “level” of experience that the developer possessed. Some junior developers understood these topics better than their senior counterparts. However, some junior developers were completely oblivious to the subject matter at all. This subject matter doesn’t seem to be something that is learned on the job so much until you begin to work on more complicated systems, however, the benefits of understanding these concepts pay off greatly when developing any piece of software and should thereby be understood as fundamental knowledge for any competent programmer.

It might surprise everyone reading this to find out that the topics and subjects I am referring to are computer science basics. In fact, most of them are covered in the early stages of the computer science curriculum.

Why is this?? Why don’t some of the most “senior” developers at some companies not understand the basics?

I’m sure everyone has their theories, but I attribute it to more and more people learning to program by unconventional ways such as boot camps, websites that teach you how to code (like code academy), and people just teaching themselves how to code an application and get it up an running.

There is nothing at all wrong with learning like this (I’ve learned many subjects this way), but please realize that after completing a boot camp or code academy course, on say JavaScript, there is still A LOT more to be learned. I believe some people fall into a false sense of security thinking that they have all the tools they need to code anything and everything, but then end up failing miserably at a project that takes a much deeper understanding of computer science.

Developers need to understand data structures, algorithm development, and topics such as recursion. These are the building blocks of computer science! These aren’t as “fun” for your average new programmer that just wants to type  alert(“Hello World”) into a script and see the console print his statement. No, these are more fun when you actually have difficult problems to be solved and need an efficient and elegant solution to do the job.

Strangely, the same “senior” developers that are not familiar with these general fundamental topics are for some reason well versed in specialized topics such as the idiosyncratic behavior of a certain compiler for a certain language or the details of a certain system methods that may produce better timings in certain situations.

While the latter may be important to know and understand in certain situations (and I’m not implying that these people are not very useful), you can’t neglect the fundamentals. You need to fully understand data structures and algorithms before you start using the .Sort() function in your language of choice or any other basic algorithm that is implemented for you by the API. If you couldn’t write the basic implementation of the function you are using then you shouldn’t be using it because you don’t understand it.

It may sound harsh, but a programmer that uses functions that he doesn’t understand is kind of like a race car driver that doesn’t know how an engine works. If something goes wrong the race car driver couldn’t fix his own car. Yes, he is valuable to be able to drive the car, just as programmers that don’t understand computer science basics can still build software. However, I believe it is a recipe for disaster.

If you are programming by coincidence, then you aren’t sure why your code works the way it does, and more importantly you won’t understand why it doesn’t work. 

If you still aren’t sure what I’m talking about then here is a test. Can you reverse a singly linked list?

Proving that you can do this will mean that you at least understand the basics of computer science. To successfully develop an algorithm to do this you will need to understand pointers, recursion or iteration, and algorithm development. Like I’ve stated earlier, all of these are subject covered in computer science 101.

A linked list is probably the most basic data structure in computer science and is the main building block that other data structures consist of. Knowing this you should be able to develop and algorithm that, given the head node, will return the reversed node.

Test yourself. See if you can implement an efficient algorithm. Then check out my solution. Was it like yours?

The Idea behind Reversing a Singly Linked List

The idea is to iterate through the complete linked list and maintain three pointers as listed below:

• Pointer to the head of unreversed list headOfUnReversedLL.
• Pointer to the head of reversed list headOfReversedLL.
• Pointer to the node to be reversed nodeToReverse.

In each iteration we follow the below steps:

1. The headOfReversedLL pointer must point to the nodeToReverse. Initially the node to reverse is null, so the head of reversed linked list will point to null.
2. The nodeToReverse pointer should point to the head of the unreversed list as we are trying to reverse that particular node.
3. The headOfUnReversedLL pointer should move one step forward in the unreversed linked list.
4. The next pointer of nodeToReverse node should point to the head of the reversed linked list.
   We repeat the above four steps until the headOfUnReversedLL points to null.Here is a pictorial representation of the iteration. Each row represents the state of the linked list after one iteration
   
   So, if we observe closely, the first step is actually the finalizing step of the iteration. That is the step which correctly positions the headOfReversedLL to the node which was reversed in the last iteration.

   But, when the loop exits out, we never get a chance to do that one last time. So at the end, let us re-position the headOfReversedLL to the correct node nodeToReverse

   Source Code – Reversing a Singly Linked List

   1 2 3 4 5 6 7 8 9 10 11 12 13

   private Node reverse(Node h0) {     Node headOfUnReversedLL = h0;     Node headOfReversedLL = null;     Node nodeToReverse = null;     while (headOfUnReversedLL != null) {         headOfReversedLL = nodeToReverse;         nodeToReverse = headOfUnReversedLL;         headOfUnReversedLL = headOfUnReversedLL.next;         nodeToReverse.next = headOfReversedLL;     }     headOfReversedLL = nodeToReverse;     return headOfReversedLL; }

   Analysis – Reversing a Singly Linked List

   Running Time

   We just run through the linked list once and hence the time complexity is O(N) where N is the size of the linked list.

   Space Complexity

   We just use three more pointers and that is not dependent on the size of the linked list, its O(1). Hence, we can say that the space used is constant.

If you were able to come to this solution or one like it then you are one of the better developers! Congrats! If not, that is okay too! You can’t become better and master a subject until you realize what you don’t fully understand. If this was difficult for you then I suggest picking up a basic computer science book and going over the basics a little more until you have a firm grasp and understanding of the subject matter.

I hope you like this post. Please comment and let me know if you disagree or agree with the article. Also please subscribe to my blog at jasonroell.com.