In the ever-growing field of software engineering, continually learning is essential. While a lot of developers internally have the drive, they're stuck in a team that externally makes it difficult to learn. Here is a checklist of simple questions to gage how much a team encourages learning.
Spending money
Will managers buy a technical book without giving the developer a hassle? For management to spend $30 on a book, for which a developer then spends dozens of personal hours digesting and learning a whole new skill, is an incredible rate of return. If management is too short-sighted for that ("aw, can't you get it online", "did you check your local library first", "the project budget can't afford that", etc...), then your team is toast. Of course a developer could abuse this by requesting to fill an entire book shelf, so common sense applies. A book is month is very reasonable.
Will management provide adequate resources to explore a new task? For example, if you're investigating continual integration, you will need a spare build server.
Encouraging team collaboration
Can your team set up a wiki such that everyone can easily share trivia and knowledge?
Are code reviews encouraged by all the managers and influential contributors?
Do senior team members actively mentor junior members, or are developers too busy pounding out features to "waste" on mentoring?
Scheduling
Do most features allot at least some time for research and improvement - even 5-10%? That means if you spend a whole week plugging away at a feature, management is okay if you take at least a few hours to explore a tangent, or incrementally improve the system?
Microsoft, as well as many user groups, occasionally sponsor free local events. Management may not pay thousands to send you to fancy training, but will they at least let you occasionally take the day to attend a free training session?
Process
Do your processes display public results, and are those processes documented, such that anyone on the team can investigate and understand them? Or, are the processes cautiously guarded by some "builder master" guru or manager who doesn't want anyone else to see the big picture for fear that it would somehow "threaten" them?
Features
Are the interesting features shared across the team, such that everyone gets a chance to explore cool technologies, or does the architect/team-lead hog the cool features for themselves and leave the boring work to others?
When your team needs a research project, is it assigned internally so that your own guys get the opportunity to learn about it, or is it sold off to some external consultants, or is research forbidden altogether ("we don't have time/money to learn to do things better")?
Management
Development requires innovation, which requires risk, which inevitably results in the occasional "failure". Does management allow developers to take a calculated risk (i.e. not belittling or embarrassing the developer when it doesn't work out)? If not, developers will be afraid to innovate, which means they're be afraid to apply what they've learned, which will reduce their incentive to learn new things.
Will management emphasize the total cost of ownership, which ultimately can only be reduced by continual education of the entire team? If managers only emphasize the current task ("we don't have time to do it right, we need to get this feature coded now."), and learning (even if it's for the current task) means you're not actually programming (i.e. "typing in keystrokes") at that moment, then managers will discourage developers from learning. In other words, is learning seen as a first-class task?
Does your promotion system emphasize career goals, which in turn emphasize some learning goal?
These things do not necessarily imply a good or bad learning environment:
Sending developers to expensive training - Back during the .com bubble, there was plenty of cash to send anyone to training. However, as mentioned above, there are still plenty of ways for a company to encourage learning without sending the developer to a fancy training session.
Asking you to handle an occasional boring task - Ultimately any engineering project will have something tedious and boring that needs to be done. This doesn't mean that the team is anti-learning. However, if every task is boring and hacked, then that's an obviously bad sign.
Emailing links to "best practice" articles - Any kid can email links to coding guidelines or best practices that someone else wrote, and for which it requires the discipline of other developers to actually adhere to. There's nothing brave or helpful about yet another checklist.
No comments:
Post a Comment