At $work, I have stepped into a managerial role where I am tasked not only with the care and feeding of the other developers in my area, but the mentoring and development professionally of the junior developer that has recently come on board.

In many ways this is pretty exciting for me. I love to mentor people; watching someone develop and grow is a rare privilege not enough of us are afforded. Likewise, being able to help guarantee a positive work environment that is conducive to ridonculous level code being produced by the more senior members of my team is incredibly satisfying.

So as you can imagine, I have been doing a lot of thinking about what wisdom to impart to the new developers that will come under my care, as well as in what ways can I be of service to the team as a whole. As yet I haven't come up with many nuggets, but the ones I have landed on I think have enough merit to share.

Know when to refine, when to refactor and when to refrain.

I think this is the number one place that most developers make fatal errors. As an engineer, we are wired to look at problems and find the most elegant way to solve them. This is what gets us up every morning. This is why we do it. Unfortunately when working in an industry that is face paced, like internet technology, this tendency to over-engineer and rewrite can be a real killer.

Perhaps the best way to explain this is with a nifty graph:

As you can clearly see, when you have tight deadlines, and mountains of work, refactoring existing code that works is highly unadvisable. As a developer you must make strategic decisions about where your time is spent, and this must be informed and balanced by the needs of the company. Should you strive to craft breathtakingly beautiful code? Yes, but not at the expense of the overall velocity of your development schedule. Sometimes good enough is beautiful.

Regular communication, good for the soul, good for the team.

See what I did there, I slipped in a religious reference... don't look at me like that!

If you aren't lucky enough to work in a hip, young company that eschews the more traditional trappings of commerce, then you are familiar with the fact that your engineering/development department is usually at odds with the creative/marketing departments. It is a fact of life.

One would assume that the marketing creative camps would be the ones that should take up the task of fixing this problem, but the fact is that they usually don't know how to approach us. One too many obscure Star Trek jokes and they will go screaming back to the IKEA page they call an office.

No my friends, we as engineers need to take the initiative here, or at least share it with the other areas of our companies, if this is ever going to be solved. We are not warring city states vying for supremecy, we are legions that together create an unstoppable army. Possibly an unstoppable robot army... full of ninjas.

As someone who has been placed in a leadership role it will be you, more than anyone else on your team who will live out this mandate. Lead by example and all that rot. If you cannot help build bridges between your guys and their guys, how can you expect the developers on your team to do it?

Applying the same principle to your own team, schedule time to talk to each of the people under your care, weekly. stellar quality developers are worth treating with respect and care. Giving them a private, safe venue to talk about how they are doing will allow you to identify potential problems before they become untenable. Also, it makes your devs feel special, and everybody wants that right? — Thanks for teaching me this Steve!

Code is creative. Don't ever forget it.

There is, I think, a disconnect in todays world that convinces people, both programmy and artsy, that there isn't anything creative in what we do. This of course is completely false and incredibly demeaning to the work we do. Writing code is a voyage of discovery. There isn't one way to solve a problem, there is an ever expanding web of possibilities that can be explored, quantified and executed.

The best developers have creative instincts as good as any painter or sculptor. The developer simply thinks in terms of causality and logic, rather than shape and light. This is extremely important for you to get, and own. Don't allow yourself to abstain from discussions that seem to "artsy" or "creative".

Everyone's voice has merit, and the best answers are arrived at by considering all the possibilities. To remove your insight from the process is to damages the fabric of the solution. After all, it will be up to you and your team to help realize the solution.

You should be, nay must be involved in the process that will bring that solution to life.

Well that is all I have at the moment. I am striving to live out these three principles in my work life and so far it has borne fruit. Feel free to comment on these ideas, and to offer some of your own that you have found to be particularly useful.