4 ms·
There is a certain zealousness that comes with learning new things and looking for ways to apply them. Any programmer likes to do this regardless of experience
by courtf 5y ago
There is a certain zealousness that comes with learning new things and looking for ways to apply them. Any programmer likes to do this regardless of experience or maturity, so it's a little inaccurate to say programmers need to grow up, although perhaps a reduction in zealotry would be good.
Often workplaces don't provide programmers, especially new programmers, the opportunity to flex their new skills as they are learned. It's rare for the business to be able to function as an incubator for programming talent when there are tickets to be closed. So, we can encourage ambitious learners explore in their free time, or we can decide for ourselves to take the subversive route and shoehorn our new skills into projects to satisfy our own desires. I am not so critical of the subversive route, it can be a great source of motivation and the business doesn't need to get everything it wants all the time, the programmer can take something for herself once in a while. In the absence of a genuine dialogue with management about helping the programmer grow, it may be quite justified to behave this way.
That said, there might be a better way that involves reducing the focus on "efficiency" that has "optimized" a lot of exploratory work out of existence. There are things like 20% time and such, but getting a programmer to focus 100% on their fresh ideas is difficult for just one day a week. The cost of context switching etc. After working in a variety of small companies that were able to leave time on the table for programmers to dabble in personal interests, I have become quite skeptical of large, rich companies that don't seem to have the ability to create slack in their processes. Too much management, too much over-optimization, too many meetings and sync-ups and arbitrary metrics and other nonsense have been foisted on the workplace by various snake oil salesmen who then clog the hierarchy and continually meddle in processes with vain attempts to justify their existence.
The solution isn't obvious, even the useless need jobs after all, but a lot of this frantic over-analysis is driven from the top. The need to constantly react to the market, respond to threats and opportunities, change directions 100+ times over the course of a year as leadership squabbles over who has the reins, everyone trying to build a name for themselves as quickly as possible no matter the collateral damage etc etc. The programmers aren't the only ones who need to grow up... If a workplace could manage to cultivate calm and focus from the top (easier when you aren't in the red, of course), we might be able to allow programmers the space they need to grow as individuals, while simultaneously making the most pragmatic technology decisions needed by the business.
- Jtsummers 5y agoThe team I was with last year would exercise new language/library features (C# was their bread and butter) on one section of the system. A kind of test refactoring/development to answer the questions: Is this useful for us, do we like it, and do we understand it well enough to refactor more of the system with it. If the answer to any of those was no, they'd revert the test stuff but keep it in mind for the future (as they'd experienced it they could make a more informed decision later if it were relevant again). This let the developers get a bit more novelty in their otherwise dull (not in a bad sense, but not interesting) enterprise projects. It was also disciplined enough that if a feature was useful (did the job) but didn't aid in other ways (clarity, time to develop, etc.) then it was quickly dropped rather than letting someone run amok in the codebase. Timewise this was 1-2 sprints for them, one to ramp up, the second to really exercise it. The customer wasn't losing much time (they still did other work during the sprints, they didn't halt things to do this it was one story among many) and potentially gained (if it turned out to be useful).