- No best practices? Methodology for thinkers –Skill acquisition, the Dreyfus model, and why best practices can be limiting (= frustrating).
- Introducing deliberate discovery –Learning things and completing projects, maximizing discovery/decreasing ignorance.
Those two are really great.
The code might not be the limit?
Think of all the conferences you’ve been at or articles you’ve read. Chances are that if you are an experienced programmer quite a few of the topics you found interesting, maybe even a majority of them, are not very code/technical centric. Why is that? Isn’t your job, supposedly, code-centric and technical? Most likely I would say that is due to the simple fact that code and technical stuff is not what’s holding your productivity back…
You get, somewhat, interested in topics such as project methodology and processes, how to deliver on time, agile,… Even though project managers sound like a good target audience for such things, why aren’t your project managers at those conferences or reading those articles anyway? Simple, it’s about your work day and your frustration about not being “in the zone” all/some of the time. It is also number 8 on Joel’s list. Actually, having mentioned “Joel on Software”’s 12 steps to better code. Go have a look at it again. Just the headings are fine.
What did you find? No neat syntax stuff, no nifty patterns to make your code better, more readable/extensible/modular/reusable/less-or-/more-or-better-something. I would say that it correctly identifies non-code-centric stuff as a more common limit to successfully delivering projects/products compared to a lack of code-skills.
Technical/code skills
Sure there is a lot of value having lots of technical/code skills. Even a requirement. There are thousands of models/patterns/skills/algorithms/concepts that you should know and have experienced. Not to mention implementations of them. Of course if you don’t know about patterns, dependency injection, transactions, parallelism & concurrency etc. when you need to, especially when you don’t even know that you need too, is a quite a big limit. It’s all useful and required skills/knowledge to have in your toolbox to be able to use.
Productive
I’m just saying that, in my experience, technical/code skill level, is not what’s usually holding the productivity back (it could though be as Dan pointed out to me). Keeping people from putting those skills to good use are. This is assuming that you have a good team. Good people is a requirement. Good people know lots about this technical stuff by having a genuine interest in it, having read about it and experienced it. Even if they haven’t experienced it a whole lot they know it exists and will, and want to, learn about it. Beyond a competence level.
Now read that second bullet’s link to start learning about finding out what’s holding you back.
Minimize ignorance
It could be as simple as that you early on need to set out to visit the real world, maybe through a visit in reality with the users/environment or by prototyping or writing tests. Whatever you think would minimize the current ignorance you have about the project’s final result.
Anyway, remember, depending on skill level, “best practices” and processes could possibly limit you and your team, see that first bullet’s link again.
Learning things is useful. Learning about learning is very useful! Thanks Dan.
Bank apps, Handelsbanken, Swedbank and other Swedish banks now have some great apps!
