Help me learn how to collaborate with programmers!

December 21, 2013 6:48 PM

Hi everyone, I will soon be working on a project that involves the development of a web platform and will be hiring part-time engineers. I would like to know enough about programming and web development to be able to collaborate with them and understand the language, and have realistic expectations of when things get built. So I am not looking to learn how to program (I wish I had time for that), but rather have a basic understanding of how the system works and fits together (front-end, back-end, etc.) Anyone know of any good online resources- online courses, websites, etc. for this type of knowledge? I've checked out Code Academy and Khan Academy, but both seem heavily focused on helping you learn how to write code vs. understanding the system abstractly and holistically. But I may have missed something. Thanks in advance for your help!
posted by tessalations999 to Computers & Internet (19 answers total)

As a programmer who has had to deal with non-programming managers many times... Let me give it to you straight. There is no way to become as fluent as you would need to be to be useful to your devs in the amount of time you have. Stick to communicating the project requirements clearly and ask your devs to appoint someone responsible as liaison between you and them. Trust me on this.
posted by signsofrain at 6:58 PM on December 21, 2013 [7 favorites]

In the hiring process, I'd try to get at least one person on the team who was able to articulate a complex technical idea in terms that made sense to a layperson. This is harder than it sounds, but not impossible. You will need to be able to lean on them up front for a general timeline and also when inevitably the parts of the project that were not articulated up front surface as incremental requirements (which will probably be perceived by your non-programmer peers as bugs). Signsofrain is correct that you don't have time to get up to speed on how it all works.
posted by christinenewkirk at 7:08 PM on December 21, 2013

Sounds like you'll be doing some project management. The Mythical Man Month is one classic in this field, but I'd also try the Dummies and Idiot's Guides to (Web) Project Management. They lay things out very clearly from project inception to completion and provide a lot of understanding on how the projects work. Not sure of the nature of the project, but these books explain how to work with the team to develop effective communication and process and how to estimate timelines. Estimates should always be produced with the help of the people working on the tasks, but it's common to pad these a little if you're responsible to others for project progress.

I don't know what your previous experience with this is, but I disagree with signs of rain and christinenewkirk that this is an insurmountable challenge. Yes, I would look to hire developers who are communicative and can express complex ideas simply, but it is not uncommon or impossible for non-programmers to manage projects.
posted by sweetkid at 7:15 PM on December 21, 2013 [1 favorite]

Best answer: Understanding the development processes will probably help you more than trying to understanding systems and technologies. I suggest checking out Process topic on A List Apart, particularly the Project Management and Strategy subsections. If you’re willing to buy books, A Project Guide to UX Design and Communicating Design are terrific.
posted by thebestsophist at 7:15 PM on December 21, 2013 [1 favorite]

Programmers don't generally know how to manage programmers. There was a special track/some special classes for this where I went to school (for computer science majors), and years of experience combined with natural ability lead to some programmers being good at working with other programmers, but knowing how to program something by yourself doesn't give you this knowledge -- working on projects with other programmers can.

The most important thing you can do is hire really good programmers; then, be patient with a lot of detailed questions from them, and be very clear on how precise they can be with deadlines. Learn whether they're using "Agile" development methodologies, some other methodology, or no particular methodology.

Good luck!
posted by amtho at 7:24 PM on December 21, 2013 [1 favorite]

Call me bullheaded if you like but in my experience managers who've never coded make terrible managers for coders. It's not about people skills or project management skills... it's about intimately understanding how teams of programmers work together, how the technology employed affects productivity and workflow, and the kinds of specific problems devs run into over the course of projects. If you haven't coded or managed coders before you are underqualified and no crash course will adequately prepare you. Please, lean on someone with skills. I ask for coders everywhere.
posted by signsofrain at 7:30 PM on December 21, 2013

As others have said, getting up to speed on the technology is probably the least useful thing you can do. On the other hand, you might want to read this, for a start.
posted by Good Brain at 7:38 PM on December 21, 2013

Best answer: I will third that technical skills are not what you need, here. What will your actual role be? Project manager? Product manager? UI? Scrum master? I have been your mirror image (a technical person looking to hire a non-technical person who communicates well with developers), and here's what I've looked for:
- for requirements and UI design, someone who understands some level of object oriented design (NOT programming, just basic design or requirement units for severability).
- someone with a compatible management strategy (for instance, will you be using agile principles? Waterfall requirements?) Your biggest conflict will almost certainly be requirements management. Start out on the same page, and you'll have much less of a problem.
- either a high level understanding of back end functionality, or enough respect for your developers not to argue when they tell you "Look, I can't do that, because a database JUST DOESN'T WORK LIKE THAT."

The absolute worst thing you could do is go into a working arrangement feeling like "I've done Kahn academy, so I know how long something should take to do." Even if you don't actually say it out loud. That is absolutely guaranteed to put you on your developer's sh*t list. Hire good people, trust their advice, learn as you go, respect them and expect them to respect you.

In your shoes, with your concerns about understanding the process and timelines, I'd run this as an Agile project, where all your team will meet regularly to collaborate, you expect severable and iterative requirements, and you will have multiple "shippable" deadlines, so you limit your risk. I would definitely not recommend a waterfall style project, where you figure out what you want to build, hire a few part time engineers, and expect to hand over your requirements and get a functional product in return. (It rarely--maybe never-- works that way for experienced managers and well-oiled development teams; it's exceedingly unlikely to work for you with your current constraints.) Hire a Scrum Master, hire a requirements person, hire a UI designer, and a back-end savvy developer at a minimum. Then you are the "client" and you work with your team to figure out the right thing to build (trust me, you don't yet know what it is), and follow their advice to get it done.
posted by instamatic at 7:39 PM on December 21, 2013 [4 favorites]

Instamatic's feedback is spot on. To the aspirational list of people to hire, I'd add a quality assurance person. In my experience, "great at development" and "great at checking and validating development work" are not necessarily skill sets that overlap, even in very rigorous, process-driven environments. In an ad-hoc development environment such as the one it sounds like your work project will be, testing is quite likely to be overlooked, with potentially disastrous (example: healthcare.gov) consequences. If your budget does not allow for a testing role, then plan to add at least 40% more time to the development estimate for testing, validation, and bug fixes. I cannot emphasize too much how critical testing is. If you understand that going into the project and make time for it, you and your team are much more likely to be happy with the end results.
posted by christinenewkirk at 7:56 PM on December 21, 2013 [2 favorites]

I endorse christinenewkirk's comment. Also - try to make sure you have _some_ kind of user/usability testing, not just "will it break" testing. If you don't have a big budget for this, it can be as simple as:

Sit down with someone who knows nothing about the software (aside from what all new users should know), giving him or her some simple tasks, asking him/her to narrate his/her thought processes, and watching/listening to what happens -- there are some articles about bare-bones/simplified user testing out there, definitely don't just follow my instructions here. This can also be the difference between success and failure.
posted by amtho at 8:10 PM on December 21, 2013 [1 favorite]

Speaking verrry broadly, Programmers are people who love machines, and some of them love working with machines more than they love working with people. You are a person, so just dealing with you isn't their favorite task. On top of this, if you aren't technical, then you need to be the lowest-friction manager/PM ever: stick to short meetings, provide very specific communications, and spend your time making their jobs easier.

If you want to learn more, look for information about architecture, or your chosen stack (e.g., LAMP), or cruise through the Stack Exchange sites.

It's harsh, but I agree that this isn't something you can fake or cram in a few weeks. Be honest with Your Herd Of Nerds, and tell them you're trying and then just keep your head down.
posted by wenestvedt at 4:42 AM on December 22, 2013

Yeah, christinenewkirk and amtho are right. I almost wrote QA and user testing in my list, but I wasn't sure how far I could stretch "hire a couple of part time programmers" into a real functional team. Note: this is a dream team, though you might need a couple of programmers. I have (when very lucky) found UI folk who can do user/usability testing. And when equally lucky (and resource poor), I have occasionally found developers who are so devoted to unit testing and edge case testing that they, plus your UI team, plus you as business requirement owner MIGHT be able to take some kind of QA coverage. But really: there will be bugs. LOTS of bugs. That's how software development works. Assume that, and figure out who'd you rather have find them, your team or the public. You will probably decide it's cheaper to hire a QA person to do bug testing and management than to make your lead developer do it. They'll be more efficient, less grumpy, more able to find bugs because they won't have built them in, and likely a bit less expensive.
posted by instamatic at 5:54 AM on December 22, 2013

Best answer: I am not clear on what your specific role is on the project team and that would influence my thoughts. I am also not clear on if you have an established project team with technical resources on board and you are just looking to hire some part time folks to fill in the gaps or if you anticipate the part timers being your full development staff.

That being said, as a person who moved into IT project management without a technical background my suggestions would be:

- understand the software development life cycle
- understand the various types of testing and what they are intended to do: unit, integration, functional, joint functional, regression, smoke, performance, stress. Your team may not do all of those but you want to understand what they are intended to do if you hear the phrases thrown around. Just google them.
- understand that your development team will not alone be able to provide a completion date. They are dependent on solid requirements to begin their design/dev and shouldn't move to production aka go live until testing has signed off. Your PM should be able to work through a timeline. Understand that this timeline may not be solid until after you are further into the process. For example, our estimates for work effort, which influence your schedule, were at +\- 50% after business requirements, +\- 40% after functional requirements, +\-20% after design. The more you know, the better you are able to accurately forecast a delivery date.
- assuming you have knowledgable team members..... TRUST THEM WHEN THEY SAY THEY CAN OR CANT DO SOMETHING. the technical component is their area of expertise. You cannot fake it.
- if you want an understanding of how the front end works with the back end, I suggest speaking with someone in your specific IT organization. Some are more complex than others and it helps to learn specifics because that is what your team will be operating in. If there is a transactional record keeper and you hear your team saying it's not getting through, you need to understand enough about YOUR systems to say oh crap - That means the transaction in essence didn't happen which is not what we want. You don't need so much info that you understand it's because job z732 didn't run.
- so who an you talk to? I actually suggest it's not your developers. I found their explanations too technical to start with. If you want a high level understanding of how your systems work together, try an architect. They have the holistic picture. Also, your analyst can usually help. They liaison between the technical and business teams enough that they can usually give you the high level understanding without getting bogged down in the details.
- once you have THAT basis to work from, if you have more specific questions, try the developers. But you have to have the basics before you start with them. They do not want to explain the basics to you. You are expected to have a certain base knowledge when working with a technical team.

As far as methodology which might influence your delivery date, I am a proponent of agile or "agile like" for web work. But you have to be staffed accordingly to go true agile (small, DEDICATED teams, a dedicated room, etc) I have done agile like where we clearly define all requirements and get sign off and then move to an iterative design-build-test. We would meet several times a week and view demos, note defects, make adjustments, etc. operating that way really helped me to get a better understanding of both the requirements and the system behavior but would have one push to production because our web releases were only three times per year.
posted by polkadot at 7:14 AM on December 22, 2013 [1 favorite]

Pick up a copy of Code Complete.
posted by colin_l at 7:31 AM on December 22, 2013

Best answer: I've been doing project management of web development for several years now and would echo the comments above, especially as it relates to -not- learning how to code. It's not your "job" (at least it shouldn't be from what you've written) and it's best left to others who will do it because it's their own special ability.

Obviously many books have been written about this (one that might be helpful is Making Things Happen), and there are varying approaches for each phase of the development lifecycle. But I think the main points are consistent even if the approaches can vary widely.

I came to web development PM from a vastly different field and had to learn from scratch, just like you. It can be done, with patience, lots of Googling, and a willingness to trust your team and keep an open dialog with them. If I may be so bold, my advice would be:

- Assemble a good team, if at all possible. An experienced team will give you good estimates and will deliver a better product potentially faster (if they receive good support from you, as I am assuming you will be a kind of "product manager" for what you're building).

- Try very hard to communicate clear requirements to your engineers/developers. This is a whole process with many parts and I recommend reading a book or two on requirements collection and refinement. In my humble opinion, you can do a lot with good requirements and average developers, but the best developers in the world won't save a project with bad (or no) requirements, and they will potentially become your enemies because you didn't do the right diligence and expected them to magic things into reality. It will be, in development agency terminology, a shitshow.

- Work with a developer or engineer to hash out the requirements, if you have the ability to do so. Don't skimp on the planning — it's critical. In my position, I usually work with an engineer who sits in on sessions to make sure what is discussed is technically possible with the time budgeted and brings up things that we less-technical people never think about. If you have a good rapport with that person it can be a really fun and rewarding process. And that person will take these requirements and translate them into the appropriate dev tasks for when the thing gets built.

- Don't be afraid to ask questions and don't be afraid to ask your people to "dumb it down" for you. In my experience, some developers love to lecture (if only to avoid actually coding sometimes), and you can potentially learn a lot just by talking with them about their work. Often those chats actually help them too, especially if functionality is unclear or if there are problems that weren't initially anticipated.

- For god's sake hire QA testers. There's no substitute for good QA and you will learn a ton from experienced QA testers as well. In my opinion, this is not an optional step. I've worked on projects with little to no QA and they were always a nightmare.

Obviously it's a lot more complicated than what we've all described above. But if you have a good, supportive team, and you are supportive and flexible in return, you will learn a lot, build a good product (though never a perfect one!), and maybe even have a good time doing it. I'm assuming you have a relaxed timeline here — obviously if this is a pressure cooker project, there's going to be way less latitude in what you can do. Good luck and try to have fun!
posted by MyFrozenYear at 7:32 AM on December 22, 2013

TO add to the above:

Be honest about what you dont understand. try to draw out what you do uunderstnd and ask for correction.

Ask for estimates as broken down pieces of the project in terms of wweeks.if any estimate is more th an 2 weeks, ask for a further breakdown

Read about Agile and the Scrum Master and Product Owner roles. Those roles arent meant to be technical. One manages the process, the other validates the result
posted by jander03 at 2:55 PM on December 22, 2013

For estimates, go even shorter, like hours, 4-8 max. You don’t know anything yet because the project hasn’t started, so make sure that you’re getting the most out of your agile process by maximizing opportunities to learn as you go. The key is to be sitting with the developers, soaking it all in and playing the role of the knowledgeable client.

One important question: do you have authority in this situation? That is, if questions of interface or whatever come up, are you empowered to make a decision based on your own research, or do you need to ask higher-ups? If it’s the latter, you’ll be in a precarious position. Figure out how much rope you’ve got and use it all.
posted by migurski at 7:10 PM on December 22, 2013

Michael Lopp writes entertainingly on management, and on managing software engineers specifically. I can recommend both his book and his blog. Although I come at it from the perspective of a software engineer wanting to improve how managers work with me, it usually makes sense.
posted by danteGideon at 4:12 AM on December 23, 2013

Regarding just the hiring, I would lean on someone with programing skills to assess the first hire and then have that first hire assess the skills of the subsequent hires. There really is no way to evaluate someone's technical skills if you do not have them yourself.
posted by amileighs at 6:29 PM on December 24, 2013