(Please note: these guys were mostly at their first or second workplace, and still doing university: in Hungary, it's common that young software engineers are taken as full- or part-time employees while still studying.)
Working with students is hard. It's hard because even if they know the theoretical answers, and didn't forget them right after passing the exams, it's not yet burned into their brain with "learning-by-doing". They're not confident enough to work in an elegant way.
Behavioral pshychology has three distinct depth of knowledge categories:
- heard about it
- familiar with it ("followed")
- know it ("internalized")
Students are at most on the second level, sometimes not even there.
On the other side, students are easier to shape. The reasons why students passed on interviews more likely than "adults" is thay they didn't have burned-in bad habits, like, treating javascript as a classical language, or being careless about design and architecture.
One would expect them to come and ask, but in 99% of the time - especially in the beginning - they won't: neither our education system encourages it in reality (only on paper), nor are they confident enough to be open about missing knowledge.
In our society, it's really hard work to make people be open about their mistakes. It's even hard to express improvement and the lack of it. We hope it won't be known, and we don't really want to change, we just want to be accepted, and, above everything else, always look perfect, even with our errors: if you are losing in some fields, be a perfect loser in them, make this your ideal.
Therefore, working with students needs continous supervision, a kind of a pair programming: it's the tutor's job to make as many checkpoints for feedback as needed, at least(!) multiple times a day. It's for the tutor to check progress, not the student to present it.
We should also forget about common sense: personally I hate the word and the culture around it: it's not common sense to be part of software engineering, even if one feels it is. It's a science, with its own internal religions: one year's common sense will be next year's blatancy, as fashion comes and goes.
In the 90s, RUP was the common sense; nowadays Scrum is; neither of them is true, we've learned that you need a tremendous amount of knowledge about the actual situation, and you need to continously balance between values.
(Our industry as a whole didn't wake to this knowledge yet, so, forgive me, dear reader, if I firmly believe it shall happen soon)
The elegant solutions of seemingly simple tasks need knowledge and experience as well as confidence in your tools: if someone doesn't have enough experience with the inheritance system, he'll use copy-paste, even if he's told it's forbidden; if he doesn't have confidence in his editor, he'll ignore autocomplete hints, leading to spelling errors and later, inevitably, crashes.
Once I left for 3 weeks, of which one week I was not able to read my mails. Two of the students had a task to write a report generator tool, of a complex report which shall run overnight. The report had a preview and a complete functionality, with the preview taking a few minutes. (to those who think such slow systems shouldn't exist, our hands were tied well for a lot of reasons).
Before I left, we were discussing the steps needed to write it: they had BA specification, ready-made sql procedures to call, they had sequence diagrams and class diagrams, with about a page of accompaniing notes. One of the remarks was about the difference between how previews and full reports are handled, they had it on the margin: Use the Strategy Pattern!
(GoF, of course, was a required reading both on university and after enrollment.)
When I came back, I've found a code full of if(isPreview) and if(isFullReport)s, of course. I went to them, and asked, "why did you feel the need for this?" "We felt Strategy doesn't fit as they were only partially different". I asked them to open their e-book copy of GoF at the Strategy Pattern. Of course, it was made for problems only partially different.
Engineering is not common sense, I learned it that day.
No comments:
Post a Comment