A few days ago I had an appointment with our trainees to give them a presentation about information acquisition: how to find resources on SCN, how to learn about the inner workings of the system by debugging, exploring the source code, and so on. I improvised the session completely, which is fun because you never know what happens. The session took an unexpected turn from information acquisition to collaboration – please see for yourself.
It turned out I had three key messages for my new colleagues:
1. You can’t learn much in advance
2. Think of yourselves not as developers but as information workers.
3. Contribute and collaborate.
Here they are in more detail.
1. You can’t learn much in advance
Imagine a builder who builds all the possible houses that anyone could ask for in advance: wooden shacks, skyscrapers, round houses, square houses, houses with a sharply tilted roof, and so on, to have exactly the right house at hand when somebody comes along with their precise specification: bizarre and inefficient, not?
Gathering all the skills and knowledge to solve any technical design problem is much the same. There are so many technologies, frameworks, and tools, and so many ways to combine them, and they appear and perish and change so rapidly that it would be pointless to try to have all the required detailed knowledge at hand when you need it for a particular solution.
Fig. 1: Education
Instead, you need a meta-skill: to acquire information rapidly and develop the required skills for a particular solution on demand - to learn what you need, when you need it. Therefore it is absolutely crucial to be familiar with the most valuable information resources for SAP professionals:
- SCN blogs, articles, wikis, and forums at http://scn.sap.com/welcome
- SAP Library at http://help.sap.com/
- SAP Notes Search at http://service.sap.com/notes
- Google (need the URL? Bing it.)
- the SAP system itself (Data Dictionary, SQL trace, ABAP Repository, where-used lists, debugger, …)
If you have a good command of these, you can solve every problem and you will acquire a huge body of knowledge along the way. This knowledge will help you solve future problems quicker and better, but only as reusable (and quickly perishable) knowledge modules.
2. You’re not coders, but information workers
Our trainees are at the very beginning of their careers: College hasn’t even started for them, and they have spent only a few days at the company. So I wanted to discuss some misconceptions about the work of a developer.
Usually, novices in the software industry are given small development tasks. A senior developers breaks down a problem into small, manageable chunks which are well-defined, isolated and testable. Perhaps there is even a pseudo-code specification for the core algorithm. This is the kind of challenge junior developers often get, so they regard themselves primarily as (junior) coders. They believe that as they get quicker and better, they will become senior coders, and very frequently even managers believe this absurd nonsense. 🙂
In fact, the kind of task a senior developer performs is entirely different from what we saw above. A senior developers is asked questions like:
- “The customer wants to integrate an approval step into this business process. What would a reasonable solution look like, and how much would it cost?”
A good senior developer will add (and try to answer) many questions, of which I list only a few:
- What does the standard offer in the current and in future releases? How reliable, stable is it?
- Make or buy (i.e. use SAP standard)?
- How easily enhanceable is the solution? Can it be easily adapted to changing business requirements in the future?
- What support is there for software logistics, deployment, configuration at the customer’s site, and later adjustments (e.g. after release upgrades)?
The result of such a research task will include the costs, required skills, possible timeframe, side effects, estimate of the stability, maintainability, deployment, training, and so on. But the solution may include no coding at all.
One of my key experiences as a developer was writing a program which, as I digged deeper into the matter, became shorter and shorter until it vanished completely. Sometimes, the code you don’t write is as important as the code you do write, and the best solution is to write no program at all!
So as a developer, think of yourself as an information worker. As developers advance in their career, they learn to acquire and consume huge amounts of information, some of which has to be generated in iterative question-and-answer processes. A highly-effective information-processing process condenses and aggregates all these megabytes of information into just a few bits such as:
- It can be done easily with customizing activity XYZ.
- It can’t be done, but only at insane costs and wrecking the maintainability.
- Let’s not do it. The requirement is against everything the solution was and still is designed for.
- It can be done with a neatly integrated custom solution, and here is the outline.
- Let’s wait one year, then it can be done easily.
To perform this kind of analysis and offer this kind of solution, you have to know how to code very well, but coding is not everything.
Coding is just what people do when the senior developer can’t find a better way of implementing the functionality.
3. Contribute and collaborate
This surprised me the most because I hadn’t planned for any message along these lines at all, but it turned out to be the most important thing I had to say. I might even have sounded a bit evangelical at this point (although I did not start speaking in tongues or scripting languages).
Fig. 2: Diving signal to be together
I find it impossible to recommend using SCN without contributing to it.
- Blog about what you've just learned. Use SCN and find information that helps you. If you work on a topic that is not covered on SCN, learn about it the hard way and blog about what you learned (or post wiki entries). You don’t have to be the world’s biggest expert on a topic to help other people with it: Blog about what you learned during the past few days and help others conquer a new area of knowledge more quickly. Quite likely, they will reciprocate and write about their next steps, which will accelerate your learning as well. Helping others helps you.
- Join a great network of active contributors. If you begin to contribute, you will quickly gain the recognition of other contributors. They are a friendly and supportive crowd and will encourage and guide you as you become a regular contributor. Many of them are world-class experts and genuinely friendly, helpful people, and it’s a great experience to find yourself as part of a professional network together with these people. They are a pleasure to work with – that alone is an excellent reason to start contributing today. Seeing in realtime what the most skilled professionals in your area are working on, being able to call upon them for help (or helping them if you can), tossing questions, feedback, and all kinds of ideas back and forth are an invaluable enrichment.
- Gain recognition as an expert. If you are highly skilled in a particular field, contributing on SCN is a great opportunity to showcase your expertise and become recognized as an expert outside your own company. You might get “discovered” by a future employer, receive an invitation to an international conference as a speaker (this happened to me when I was a busy contributor to a forum in the pre-SCN era).
- The more you teach, the more you learn. Have you ever tutored someone? I find that explaining things makes the teacher develop a much better understanding of the matter (off-topic note: except my old teachers at school). So by writing a blog or wiki entry, you will learn and extend your own knowledge. Also, the more you contribute, the more your perspective on other people’s material will change. When I started to blog regularly, I began to follow the publications on SCN much more closely. I’ve made it a habit to browse through the list of recent weblogs and read the interesting ones almost every day, and this has broadened my horizon and helped me find my ways into new knowledge areas.
Conclusion
These were the three core messages to our trainees. From colleagues who work with them regularly I hear they are a bright bunch (my impression, too), so I expect they will come up with some interesting contributions. While we’re waiting for them to show up, why don’t you, dear reader, write a quick blog about that last thing you learned in your favourite knowledge area?
10 Comments
