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: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.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.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: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.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?
How to be productive as an infrequent programmer?
programming practices;documentation;productivity;time management
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 firstBuild 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.