Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My current day job is mostly project management and client liaison work, but I sometimes get involved in actual coding. I do this either because I have a clear vision of what I want the result to look like (and it's easier to implement than to explain it), because I have relevant expertise, or simply to add resources.

But I'm finding a couple of recurrent issues:

  1. The startup time to being productive can be prohibitive. Installing development tools, getting access to relevant systems, source code etc, and simply getting to the point of a first complete build.
  2. The overhead of working on a fast-moving codebase can be prohibitive. It's not unusual on one of my projects to have to completely rebuild the environment (that is, check out and build all the code again, including creating a new local database, populating it etc) every month or so.
  3. Worst of all, if I stop doing any coding for more than about 2 weeks, I completely lose all my mental "state": I don't remember where things are installed, I don't remember which of several working directories is "the right one", I don't remember how to resolve an error message I've seen several times in the past. (I suspect my mental state attrition is much faster than average.)

I would really appreciate tips from anyone else in this situation. So far, I've worked out this much:

  1. Only code in solid blocks of time - minimum 2 days. I can't get anything done at all in a few hours at a time.
  2. Document, document, document. Keep spreadsheets that store state as much as possible. If there are several systems where code is deployed, record all key directories, port numbers, user names, database names etc etc.

What else?

share|improve this question
1  
Interesting question, plenty of good answers. What I would say though is, maybe this IS the wrong approach. Professional software development suffers badly from "dabblers". Employ people with the correct skills for the correct job and things will work out a lot better. One of my biggest bugbears with software development is that is seems to many people to be easy to get into. And you know what, it is. Too easy. But that leads to crap code, and unmanageable systems down the line. It is difficult to be good at it, and that takes training and constantly honing your skills. –  Ozz Apr 18 '12 at 8:59
1  
Now, I'm not saying you need to go to college to learn to program or anything, I've met plenty of great devs that haven't and plenty of rubbish devs who did. My point is, you need to be doing it full time. You could say that about any job of course. –  Ozz Apr 18 '12 at 9:01
    
did you consider investing dev team efforts into a feature similar to MySQL 15 minutes rule? –  gnat Apr 18 '12 at 18:34
    
Ozz: I actually have a degree in software engineering, and have done a lot of hobby coding - but not much professionally. It's also not generally possible for me to "employ people with the correct skills" - my role is PM, which basically means working with whoever gets assigned. I don't get to hire. Your points about part-time devs producing inferior code are right though. –  Steve Bennett Apr 20 '12 at 1:28
add comment

3 Answers

up vote 3 down vote accepted

Your mileage may vary with the following, but this is what I would do if I were in your shoes. You're in a pretty tough spot with what you're trying to do, so hit it with powertools.

-> if you haven't yet, get the team to build a "dev VM" - a virtual machine which they use as a golden master from which to fire up VMs used for actual development.

The goal is for that VM to fire up with all tools already installed, relevant config files already in place, etc. The only thing a developer should need to do is create an account for themselves and copy in their repo keys, source control uid/pass, or whatever.

That'll help ensure anyone (you included) can quickly spin up and do a local build, and it'll help eliminate those oh-so-special "the bug is only evident if joe builds the system" moments.

-> check in your APIs first

Build a test harness for your code before the code. Call the new API you're inventing. Then build a totally non-functional API that just has the function calls, return types, etc. but no implementation other than "return("example return value") or similar.

This will give the rest of the team something to chew on. For a team that's accustomed to its members, a new member can be disruptive. This will help minimize that disruption.

-> choose a full-time developer as your "contact point" and one 5-minute conversation with them every day. No more, no less.

Let them tell you if they have any issues with what you contributed yesterday. Just listen, don't defend yourself. Then, tell them what you're hoping to roll into the code today. Absorb their feedback. Again, just listen, don't defend yourself. Thank them for helping you at the end of each of those meetings.

This is key. You're not one of the core devs - they're a team, you're an add-on to their team. Getting help from a "mentor" of sorts will pay numerous dividends, and help the team to understand you're not trying to be disruptive. Believe it or not, very probably, they will look on your contributions to the code base as disruptive, unless you go to some lengths such as this 5-minute-daily-meeting to help ensure you're engaging with the team instead of just throwing code on top of their system.

share|improve this answer
    
Excellent suggestions - especially the latter. I guess I often use a pattern like this, but not quite so strictly. I find myself the highest- and lowest- ranking member of "the team". As a coder, I'm definitely the runt - lowest familiarity with the code base, most prone to errors, and generally least productive. Very important to keep that in mind. –  Steve Bennett Apr 18 '12 at 4:56
    
The VM is a great suggestion. –  JBRWilkinson Apr 21 '12 at 14:59
    
:-) ...thanks. I've helped many dev teams get their acts together that way. –  pbr Apr 21 '12 at 23:26
add comment

Here are my thoughts on this situation:

  1. Focus on a technology to be proficient with (or a stack of techs..).

  2. Build a programmer's machine with all the software you need and keep that handy so you don't have to re-build or install things constantly.

  3. Enhance your tech. knowledge of choice by doing small projects frequently. They don't have to be work related all the time. This will allow you to focus on your weaker spots. You will gain more by spending time on learning what you don't know.

  4. Realize that it is not possible for all people to play the roles of a PM and a programmer at the same time (many can do that, but many can't). Each of these jobs demand a lot of time.

  5. Think why are your really so attached to programming. If this is what you want to do for living, make the move. If it is more of a hobby, you know better than to do that at work :)

  6. Watch your strain level, while you are trying to be good at both jobs. I am afraid that if you leave your current position one day, you won't be a star in either. Maybe you should choose one path and master it.

share|improve this answer
    
Excellent suggestions. The flipside of 1 for me is "Choose technologies to remain ignorant of". I don't touch C++, PHP, RDF or grid computing, for instance. Re: 6, in my sector (academic research support), I think flexibility and a range of skills are usually more valuable than "stars". Re: 4, worse than demanding a lot of "time", is that they demand very different approaches and attitudes. PM work requires constant monitoring of email, frequent socialising etc. Coding generally requires seclusion, concentration, blocking out distractions. It's tough to flip between these modes. –  Steve Bennett Apr 18 '12 at 5:00
    
Thanks for your comment Steve, no one can cover many (let alone) all technologies with adequate depth. The tech. world is becoming to complex to allow even dedicated professionals a chance to "mater their own domain" :) –  Emmad Kareem Apr 18 '12 at 9:03
    
Thinking more about "5.", for me I think doing some coding on the project makes me a better PM. I'm much more confident in dealings with clients, and also in decision making, when I've actually played with some code, and have a handle on its real strengths and weaknesses - rather than just taking developers' words for it. –  Steve Bennett May 3 '12 at 9:37
    
@SteveBennett, to me, I guess your situation may have to do with your current team. I see that the technical management of a project is usually too challenging in most customer environments (the fund doubles when you are on a fixed-time contract). Also, maybe you want to test your team's feedback quality and help them learn how to provide accurate answers rather than doing the detailed work for yourself. In any way, make sure you enjoy the journey! –  Emmad Kareem May 4 '12 at 2:35
add comment

Best option is don't code, your first reason is one of the worst for doing the code - sit down with a developer and pass on you superior knowledge and skills - learn to let it go or you never will. The second reason is commendable, but I find it rare that a a PM coding will make the team go faster than the PM doing the stuff that is not coding, that stops the full time coders coding.

Your job is project manager, and as such is to maximize the teams productivity. Professional coding is a job that needs dedication and commitment, not something that you slot into your spare time. A PM needs to be able to be interrupted. Thats a bad way to program. The two jobs only mix well in teams of less than 2.

Rather than code, ask yourself what jobs your top developers do that you can do for them. Can you test, write up requirements technical or user manuals, Can you help with code reviews, make them coffee and order in pizza.... i.e. You do the stuff you are good at and let them focus on the stuff they are good at.

If you must code, I suggest work on non time-critical defect fixes and minor features. It's work that must be done but won't matter if it's "late". If it is important in any way - let the experts do it.

share|improve this answer
    
Good points. I'm often finding that there is actually not enough "project management" to do. I'm on 4 projects, each of around 1-2 FTE. Code reviews is certainly an interesting idea, but would need to tread carefully. Re: non-time-critical defect fixes and minor features - good thought. You're basically saying "stay off the critical path" which sounds like good advice. –  Steve Bennett Apr 18 '12 at 4:52
    
mattnz's answer is great, but to answer your comment- if you have some time for coding-like activities and can't stay away, consider doing code reviews for the other engineers or writing Unit Tests - both will help with quality and likely contribute to project success. –  JBRWilkinson Apr 21 '12 at 12:28
    
good thought re: unit tests. Code reviews I'd have to be careful with, as they're better programmers than me. I sometimes write source code docs as a way of improving code quality and familiarising myself with the code. –  Steve Bennett May 4 '12 at 7:45
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.