There I was, in the middle of modifying by hand several hundred files in my IDE, which I'd found from a search, but I had to replace the thing I'd searched for, & then change a part of the next two or three lines (which varied). I kept thinking that my twenty years IT industry experience was not really being put to the best possible use. I often think at that point "Who can I get to waste their time in my place?", & I generally don't have an answer.
This is a part of the democratisation of software development. Agile methodologies, in particular, demand that all contributors to the product development process have equal value - almost regardless of experience. This is a wonderful ideal that many people don't see the practicality of - that is, ownership is shared, & you are effectively producing quality output for your own benefit, not for someone else's.
This is all well & good until you expect a recent graduate to understand the intricacies of enterprise architecture or a new person on the team to estimate the time it will take for a bugfix. Experience within the team (independent of industry experience) has to be 'worth' something. It has to be considered valuable. If it has value, then it should be treated as valuable, & therefore the more mindless tasks should be foisted on others - like contractors, who should be considered short-term & not worth training, & juniors, who need to learn through experience.
The increasingly short attention span of youth, if you'll allow me to turn crusty, & instant gratification of online learning does not mean that experience no longer has value. It means that it is under-appreciated.
This is wrong.
Once upon a time, young boys were apprenticed to masters of their trade for many years, often at their parents' expense, with the expectation that learning the trade would thereafter set them up for life. The master's approach was that a young boy needed to learn the ropes by doing simple things that didn't directly contribute to the trade - just to gain experience in what the trade was about. The classic examples coming right up to the modern age including sending the apprentice to get the lunches, or to the local hardware to buy tools (with the associated jokes).
Those days are dying. When it comes to the more skilled employment of professionals, from doctors & lawyers to engineers, the education received away from the professional environment makes the new apprentice more mature (sometimes well into their twenties), & self-assured. That is, they think they already know everything. Wisdom suggests that they know nothing until they are placed at the disposal of a master, but most university graduates have never been taught wisdom.
Toiling through my collection of files to modify, I could give up & write a script of some kind to perform this one-off modification. To me, at my time of life, this sounds like a bit of a waste of time. For an apprentice, it would be a wonderful learning experience, & I wouldn't care if it took them twice as long to complete than simply performing the manual task - they'll get better at it, & better at assessing whether it's worth it to write the script. In the process, they'll get exposed to the process. This is what apprentices do.
We tend to forget, sometimes, that a graduate engineer has no experience & very little skill in the industry. They are a blank canvas, a potential to contribute to the organisation, either directly or through assisting a master engineer. They are not an instant professional. They should not be encouraged to think that they are.
Although I can't see the old trade designations - apprentice/journeyman/master being applied to software development, we have had the concepts lying around the whole time - junior dev/dev/senior dev - & yet those meanings have fallen by the wayside. We lack structure in our approach to product development, which is a reflection of agile approaches, which tend to encourage more fluid structures. In fact, they don't advocate such structures, but some people have taken their own laziness & agile's lack of application to these areas as a good enough reason to no longer be vigilant about what goes on around the product development process. By all means, allow the team to direct itself as a group of professionals, but someone - management - needs to ensure that the professionalism rises to its true potential & the organisation benefits from agility.
There we have the next problem - management's essential role in ensuring that, outside of developing the product, someone is making sure that the organisation is on track, the community within it is alive & well & growing, across all of its parts. In essence, those working at the coal-face don't have the time or energy to think about such things, & they never have. Those who produce, using the resources (capital) provided by management, need leadership to achieve their goals. They need strategies. They need someone of a different class - outside of their day-to-day - to direct.
Democracy amongst equals is all well & good, but a true society needs the benefits of the class system.
No comments:
Post a Comment