Journal Articles
Browse in : |
All
> Journals
> CVu
> 143
(9)
All > Journal Columns > Professionalism (40) Any of these categories - All of these categories |
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: Professionalism in Programming #14
Author: Administrator
Date: 03 June 2002 13:15:52 +01:00 or Mon, 03 June 2002 13:15:52 +01:00
Summary:
There and Back Again
Body:
Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveller, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;
(Robert Frost [Frost])
It's good every now and again to step back and look at where you are. It's not too introspective (as long as you don't do it too often). I'm presuming that if you're reading this you aspire to be a more professional programmer. To do this you need to know where you are now, and where you want to be. Then you can start to work out how to get there.
We all stand somewhere on a scale between programming novice and guru. It can certainly be a pretty hard call to determine 'where' you are, and the distinction can be somewhat arbitrary. Still, we could try to imagine this scale as a road. It starts off a thin but well marked out track at the novice end - the first steps of learning are relatively clear (at least as you look back at them). There a number of good textbooks, types of course to take, places to get programming experience.
As you gain more experience and understanding there are more areas you can investigate, and more ways to learn. The road branches and fans out. The choices proliferate. In your programming 'career' there will be a myriad of choices and directions you can take, different specialisations and new technologies to learn about.
We're all somewhere on this road to guruship. What makes it more interesting is this fact that it's not just the one place we're all headed. It would be boring if we all knew exactly the same thing, anyway...
Whilst flirting with the danger of turning this column into a philosophy lecture, we'll ask "What makes an expert?" and "How to you get to be an expert?" Perhaps the more pertinent question is, "How do you know when you're an expert?" Or at the very least, "How do you know when you're no longer a novice?" Expertise is a very subjective quality, but the driving force here is the desire to improve ourselves as programmers.
Programming is an interesting field. There are so many subtleties to master, and conflicting forces to be able to balance. One of the reasons that I love doing this so much is that there is always a new challenge to overcome, some new technology to learn and master.
You often hear talk of 'gurus', of experts in their fields. The rocket scientists who seem to be able to hold so much disparate information and arcane technical detail in their heads, and solve the most incredibly complex problems, that they are held in reverent awe. How many of us whish we were like that? Honestly?[1] Maybe being an expert is just growing long hair and a beard, wearing sandals and speaking in some sort of pseudo-technobabble that no normal mortal can understand. Or perhaps that's just how to look like you're an expert.
So what does make an expert? Obviously, an expert is someone who excels in his or her particular field. In 'programming' there are actually many different fields to be an expert in; for example knowing a programming language inside-out, knowing a platform technology intimately, understanding a problem domain deeply, being able to craft exceptional interfaces, and so on.
To just seek to become an expert for it's own sake is pretty meaningless. I would suggest that expertise is just a function of time spent studying, learning, developing and practising, mixed with the appropriate personal characteristics. For this reason, we should really be asking how to develop our skills where we are and the rest will follow.
The essential attributes of a good programmer are knowledge, experience, and character. The right mix of these leads to that exceptional type of person. We need to aim to develop these traits.
Some of this will come with time. Most of it all comes with some effort (i.e., you don't get to be 'good' for free, you have to work at it). However, some of this can't be worked at and are just traits of certain types of people. This shows us that at least some aspects of "guruship" are nature not nurture.
Let's look at those three in a little more depth.
Knowledge Learn. Simple as that. What's your field? What do you know now? What do you want to know? Does it focus around a programming methodology or a language? A technology? A market segment? Think carefully here, and don't narrow yourself into a single narrow niche, otherwise your view can become very shallow.
What matters is more than just understanding the details of a given subject, although undoubtedly that's important. Often the technical knowledge is the easy part, it's knowing how to use it that makes the difference. This leads on to the other two points…
Experience Practise. Try things for fun. Discover new technologies and use them. Keep going, keep playing, keep working. This is a clincher, really. You need to have been doing something, and doing it well, and doing it for long enough to know that you're doing it well.
Character A good programmer has a number of key qualities, for example: intelligence, humility, and a curiosity that drives you to find better programming solutions. That investigative, inquisitive mindset is seen in all good programmers. Communication is important; if you can't communicate you can be an adequate programmer, but not a good engineer - programming is all about communication. The programmer needs to be able to cooperate effectively. They have creativity and discipline. They are careful, for example always placing code in a repository, don't rush out quick hacks, and think before typing. They have a logical, methodical approach and are able to think at the right level of abstraction (not cluttered by language details, but able to incorporate them into work).
So how do we get "there" (wherever it is)? How do we improve ourselves? I'll fire out some suggestions here. Perhaps some will speak more to you than others. Mull them over.
-
Get your head down, enjoy learning, enjoy working, absorb what you're doing.
-
Discover the standard tomes for the subjects you're working on. How do you find them? Ask people who will know. Read ACCU book reviews.
-
Read books on software engineering to get a good view of the whole subject.
-
Make sure you know where to find out what you'll need to know.
No one knows everything, but do you know where to go for information? Which books, websites, newsgroups, magazines are relevant?
-
Get a good understanding of algorithms and data structures (read good books on this).
-
Know your tools. Know your language. Know what you can really do with your compiler and get to understand the frightening-looking programming tricks that you don't use (and may never use). If you at least understand them your knowledge and outlook are enriched.
-
Have outside interests that you can use as a frame of reference for technological knowledge. If all you know is programming you are a very two dimensional person, and will not be able to slot what you do into the context of the Real World.
-
Always write clear, self-documenting code.
-
Understand how to make trade-offs. Know the "rules" and when to break them (e.g. this class needs to have a large interface because…).
-
Be able to debug, diagnose faults, drill down to find their cause. Be able to use appropriate tools, debuggers, etc, but more importantly your mind.
-
Be able to test correctly. Know how to write exhaustive test harnesses to catch potential problems before they become issues.
-
Get better at communication. Better at writing specifications, and interpreting them.
-
Study great programs that other people have written.
-
Learn the theory, do the practice.
-
Find out different ways of working, don't stick to what you know. Learn other languages, operating systems, paradigms. Learn scripting languages.
-
Learn assembly language. Really! If you know how what's going on at the lowest level you have a better frame of reference for the rest of the OS, and a much more realistic view of the whole system. This means know how to program for real, not just 'read a book on assembly'. This point is often written off as a 'old man's approach' but it has a lot of merit.
-
Seek to be mentored by someone you admire. This is excellent. It's a big step of humility to ask for this, but a good mentorship will develop you incredibly.
-
When you are ready, mentor someone yourself - it helps to challenge and stretch you, solidifies your knowledge, and sharpens your ability to explain technical detail in depth.
-
Have a 'high level' view and a 'low level' view (i.e., program/module versus algorithm/code).
-
Be able to give names to things (there is great power in a name, and greater power in naming it; this power can be easily abused). It matters. Check with others that your names are appropriate.
-
Admit you don't know it all.
-
Know your limitations. In many ways this the hardest point here. Think about it carefully. What are you capable of? What are you learning but not able to do yet? In many cases you don't know you have a limitation until you work through it. A thoughtful understanding of your limitations can lead you to more focused personal development or more careful and correct programming.
Another important aspect to developing as a programmer is keeping yourself up to date. Most programming fields move at a rapid pace. Having learnt the ropes at one point doesn't mean you know it all for life. The cutting edge moves on and if you don't keep a view of it you'll stagnate. What we do now may not make any sense in 5-10 years time.
You're walking down the road towards a moving destination. Now that's not exactly helpful, and can be quite frustrating, but it makes the journey great fun.
It is our own responsibility to keep our skills up to date, no one else's. Read the latest books. Subscribe to the appropriate magazines and periodicals. Write about what you know and seek criticism (C Vu, anyone?). Go to conferences (the ACCU conference, anyone?). Keep up with the industry news, from websites, newsgroups and print publications. Most of all, use what you know on modern projects using current tools and development environments.
This industry moves fast. What it means to be an expert one day is different from the next, let alone in a month or a year's time.
It can be argued that the worst programming languages are those that need 'gurus' to understand them, so we shouldn't need to be gurus. However, a programmer in the complete sense isn't just a code monkey. A programmer is:
-
a designer,
-
a detective (they need to be a problem solver),
-
a craftsman (seeing code as art, with balance and aesthetics, understanding the place of the artistry within the engineering/mechanics of putting a program together - experts appreciate the elegance of a well crafted program),
-
a communicator, and
-
a team player.
An experienced programmer should be able to perform the following tasks:
-
write small programs from scratch in given language,
-
write large programs from scratch using standard libraries facilities and other third party libraries,
-
do this with more than one language,
-
write clear, self-documenting code,
-
start working on existing codebases comfortably and sensitively,
-
write complete test harnesses, perform proper testing and validation, with appropriate debugging,
-
add a self-contained "module" of functionality to a system,
-
maintain code and fix bugs, and
-
architect new programming solutions.
They have a complete overview of development/deployment process and understand where they fit into their development team/company, knowing exactly their roles and responsibilities.
With more responsibility comes the need to lead and manage the generation of large systems, to be able to create specifications for these large systems, and coordinate the programming sub-tasks, ensuring they fit together properly. They can develop their skills, and also understand the skills of other programmers - working with them appropriately.
Given all this, we'll ask again what makes an expert. Above all else, expertise is acclaimed, not self-proclaimed. It is essentially a recognised characteristic. It's somewhat meaningless to claim to be an expert unless other experts in the field recognise you as such. If your field has no other experts then you're in an enviable position and probably able to command a lot of respect and make a lot of money whilst having all the technical skills of a charlatan witch doctor.
How do you know when you're there? It's when other people tell you!
As ever, I'm after responses. What are people's views on the following subjects?
- Certification
-
It is worth it? What value does it give you, and does it really help you develop as a programmer and more than other personal development routes.
- University/college courses
-
just how capable a programmer do they make you?
I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood and I -
I took the one less travelled by,
And that has made all the difference.
(Robert Frost [Frost])
At points we may have strayed too near to bar-room philosophy here. Never mind. What we've established is that life is a journey. Learning is a journey. Moving from being a novice programmer to a 'guru' (whatever that means) is a journey.
We should be not just aiming to become experts, but actively seeking to develop skills and character at the place on the road we currently stand. There's a lot to being a programmer, and it's not necessarily all about programming.
It's only when you're recognised as an "expert" and it appears that you're "there" that you realise how much you don't know, and that there's so much further to go.
[1] Not everyone, I'm sure. But an awful lot of people secretly wish they were gurus, and like it when people think (rightly or wrongly) that they are.
Notes:
More fields may be available via dynamicdata ..