No matter what any recruiter will tell you, you alone are responsible for your career. That means ongoing education and working on a team with proper software development practices.
These practices will help ensure that you spend your time having fun building new things rather than the Very Bad Things which happen when they are not in place (trust me on this). No matter whether you are applying to your first gig in IT or you are a master engineer, it is your responsibility to assess a potential employer during the interview process. If these things are not in place already, your employer should be open to doing them.
- Do you use source control? What kind? What are you requirements/to check in code (assignment to tasks, unit tests, peer review, etc)? Absolutely refuse to work anywhere which refuses to do this.
- Do you use process/task/bug management system to track all work? How do you track progress and manage change? Is your process management tool integrated with your source control?
- Do you use the best tools money can buy? For example: MSDN/Apple Dev accounts, dual monitors, powerful workstations (SSD, 16GB RAM, i5+), and tools like ReSharper, RedGate, etc. Don’t work for bosses who don’t value your time.
- Do you have a dedicated QA team/role? Are they involved in the requirement/release management process? Developers make very bad testers—make sure your team has a formal process for testing
- Do programmers have quiet working conditions and rooms to meet? Show them to me.
- Do you get feedback from customers during the development process?
- Do you have a continous integration server? Do your builds include automated integration/unit tests? Do you have a QA/UAT environment?
- Do you create specification/requirements documents? Do you do it before, during, or after writing code? Depends on whether you use an agile/Scrum or some other process, but there should be some sort of written requirements for all work.
- Do you have a daily standup or regular team meeting? Not everyone can use a Scrum-style methodology, but every team should have a regularly scheduled status meeting. It should be daily for teams working full time in the same office, and not less than weekly in other cases.
- Do you use modern frameworks? Not every team is required to use bleeding-edge development frameworks, languages, etc. However, software productivity IDE’s and frameworks improve quickly, and an old toolset (Visual Studio 2005, VB.Net, Android IDE in Eclipse, PHP 5.3, etc.) is a bad sign.
Credit for most of the questions goes to Joel Spolsky’s The Joel Test.
Do you use source control?
We use subversion, but I rarely branch and merge. Resolving conflicts after they occur is often easier said than done. Locking code is usually more efficient. If locking poses a problem, branching to avoid the problem often masks other problems, like poor communication and poorly normalized code.
If someone else is changing code that I need to change, don’t I need to communicate with the other developer? Why does this communication not take place? Why would I defer it? Why is a file locked for long periods? Can the code be divided into smaller components that can be changed independently with less risk of conflict? Is ownership of code poorly distributed? Does the code’s organization contribute to a tragedy of the commons?
Do you use process/task/bug management system to track all work?
We use bugzilla, and I agree that task tracking is useful, but task tracking software is only as effective as its users. Sophisticated task tracking software with many bells and whistles may not be any more effective than a checklist in a spreadsheet. If a project manager doesn’t know the details of a project well enough to manage this spreadsheet, he isn’t contributing anything to the project.
Do you use the best tools money can buy?
No. I don’t want the biggest laptop or two monitors. Can I find something to do with a second monitor? Sure, but I like portability and rarely if ever need two monitors. Developers need quality, reliable equipment but shouldn’t use the fastest machines on the market or the latest version of an OS and other software unless their users have these resources.
Do you have a dedicated QA team/role?
A dedicated QA team is not all it’s cracked up to be, unless the team members are good coders or qualified users themselves. A QA team must understand requirements as thoroughly as the development team, and that’s easier said than done. Testing my own code is a challenge, but an experienced, disciplined coder will test his own code better than a typical QA team.
QA roles on a development team, with good developers testing each other’s code by developing test procedures and the like, seems more workable. A QA team mimicking end users in a staging area could also be effective, but this team must thoroughly understand what end users require. If the QA team understands these requirements no better than developers, they’ll test the code no better.
Do programmers have quiet working conditions and rooms to meet? Show them to me.
I work at home and meet almost exclusively online. A quiet place to work without distractions is definitely important, but meeting physically in the same room is becoming less valuable. Whiteboarding is still useful occasionally, and a literal whiteboard is much more flexible than online tools, particularly if people aren’t adept at using the tools.
Do you get feedback from customers during the development process?
Yes. We work closely with customers. Customers should be an integral part of the development cycle. We development incrementally and deliver early and often. Avoiding scope creep with this approach is a challenge, but the approach is far more effective than designing with customers for weeks, locking coders away for weeks and then delivering, particularly if the coders are not the designers.
Do you have a continuous integration server?
I usually develop on a VM integrated with a model of the production environment, and this development VM is the integration server. Delivering builds to a test environment separated from the development environment is also useful, but end users should be integral to this environment. Ideally, customers create and manage the environment. We work this way more and more.
Do you create specification/requirements documents?
Before, during and after development. We don’t design and then code. We develop both simultaneously. A design document is a living document throughout the development process, and a prototype may precede a detailed design. This approach requires discipline. The prototype must not morph sloppily into the final product.
Do you have a daily standup or regular team meeting?
Yes. For a typical project, a meeting or two per week is necessary, and meeting more frequently is often unproductive. Pro forma meetings should be avoided.
Do you use modern frameworks?
I use VS 2010 and feel no need to upgrade at this point. Always upgrading to the latest version of an IDE, or any other software, is unproductive and only encourages bloat. IDE changes are often arbitrary and capricious. Moving menu items around is not an enhancement. It’s more like evidence that Microsoft’s product managers have nothing better to do.
Great post! It definitely helps for people to have an insider’s account of the industry before they start applying anywhere.
I think I know just the person to forward this to 🙂