Monday morning thoughts: programmers and identity
In this post, I look at how some programmers identify strongly with a particular language, consider the meanings of ‘programmer’, ‘coder’ and ‘developer’, and what it means for us as the SAP enterprise programming landscape changes.
I watched a couple of talks by Kevlin Henney last week while travelling to and from SAP CodeJam Guetersloh. One of the (many interesting) things he suggested was that some programmers strongly identify with a particular language. This immediately reminded me of the situation within our SAP developer ecosphere, where it appears that there are some programmers that strongly identify with the ABAP language. One could even go so far as to say that this strong identification is an exclusive one. “I’m an ABAP programmer” is a phrase that I’ve heard many times before and has carried the implication “… and I wouldn’t consider taking on any other language, just give me ABAP programming tasks to complete, please”.
Single-language programmers
The recognition of this type of single-language programmer is not new, nor is it particular to the SAP or enterprise world. “I’m a <insert name of popular language> programmer” is something one hears in many situations. And “I’m an ABAP programmer” is definitely relevant in our shared journey right now, as the world beneath our feet changes and moves to the cloud.
Naturally, there are advantages to specialism. Experts in any area are sought after, and their deep knowledge and close connection to the subject is very valuable. But this expertise shouldn’t come at any cost, and the cost here is a restriction on what can be achieved.
This isn’t even about the idea that one should be passionate about one’s subject area — in this case, ABAP — nor is it about whether someone should “take their work home with them” and spend some of their valuable free time reading up and around the subject of the ABAP language. (Finding something you’re interested in beyond the day job makes work seem less like work, but that’s a digression we should pick up another time).
Coder, programmer, developer
Where does this concept of a single-language programmer come from? I think that it has a lot to do with architectures and software practices from earlier times.
First, earlier architectures and computing infrastructure was simpler, and entire solutions were built on a specific OS using a single language. So having a look back at our own world, this has predominantly been ABAP, with the transaction-oriented, dynpro-based facilities where everything from integration mechanisms, backend business logic and frontend flow was written in ABAP and developed & executed on a monolith.
SAP R/2 dynpro, image from SAP Design Guild
We see something similar in the Java world, and going back even further we come to COBOL. The story is the same each time. And while we’re back in those times, let’s consider the software practices of the day. The waterfall approach to building a solution dominated the industry. The role of an ABAP programmer was very defined, and you could point to the part in the flow where ABAP development kicked in. Turning specifications into modulpools for transactions, into function modules & function groups (function pools, ahh, fond memories), and into reports.
In the days when the phrase WRICEF, standing for “workflows, reports, interfaces, conversions, enhancements, forms”, was used almost as a currency (it still is today in some areas, depressingly), the role of an ABAP programmer was someone who turned specifications into executable code.
This role view meant that the act of programming was considered non value adding, and perhaps the meaning is carried today with the word “coder”. After all the hard and creative work is done, talking to the users and designing a set of specifications, the subsequent step just turns that creativity into something that will execute and display the ideas on the screen. Right? Not quite. This idea is as wrong as it has been damaging. But let’s leave this subject for another post.
If “programmer” is what we’re considering as the term for someone proficient in and focused on a particular language, and “coder” is the wrong extreme end of that concept, then perhaps we can think of “developer” as the correct other extreme end and a contrast to everything the word “coder” represents.
Development is a creative task, and creators, artists, use more than a single tube of red pigment on the canvas. Except for, perhaps, someone like Mark Rothko.
Untitled 1959 (from the Seagram Murals), by Mark Rothko (from the Tate Modern)
Like those artists, the developer’s toolset is not restricted to one colour, or a single paintbrush. Moreover, the canvas that we find ourselves looking at has changed so dramatically that the idea of using a single dimension to express the ideas, to realise the design, to produce the solution, doesn’t compute.
Today’s development canvas
In previous posts in this Monday morning thoughts series, I’ve mused on the landscape of today: cloud first, and composed of many moving parts. The developer must grow and thrive to continue to be able to provide creative and effective solutions to business problems in today’s multi-platform, multi-system and multi-layer world. Just look at the array of languages and toolkits that many folks wield on a daily basis. Let’s pick just one scenario that should at least be familiar to many of us – developing apps in the Fiori world: ABAP, Core Data Services (CDS) definitions and metadata extensions, UI5, XML, JavaScript, Cascading Style Sheets (CSS), HTTP. There’s a similar pattern beautifully illustrated in the new Business Application programming model documentation where the Getting Started tutorial, aimed at today’s developers, takes the reader through a data definition language reminiscent of River Data Services (RDS), the OData protocol, and more in the first few minutes, without even the twitch of an eye.
Beyond specific languages and syntax, the cloud native environment and runtimes on the SAP Cloud Platform ask for a breadth of competence that is beyond any single language. Even the platform itself is explicitly and proudly multi-lingual; sure, choose your own language, but be prepared to have conversations with your fellow developers and with other teams that might not speak the same language or see things through the same lenses.
ABAP is coming to the cloud, that much we know. But remember what that is, and what that represents. It’s not a lift-and-shift operation that brings with it the kitchen sink; it’s a subset of language features that makes sense in a cloud runtime context, with a whitelist-based set of limitations. I see cloud flavoured ABAP as much a glue language as anything else, that allows us to bind together programmers and programming layers for new solutions. And any glue language is just that. Not the ABAP that we grew up with, but, shoulder to shoulder with other languages and protocols, just one part of the overall solution.
The value of a developer in today’s world is based not only on depth of knowledge, but on that depth multiplied by the breadth across the platform spectrum.
Final observations
On a personal level I’ve always been fascinated by languages (spoken and programmed) and I’ve found that knowing about one language helps me understand another. Over my working life I’ve learnt enough languages to make myself dangerous, but also develop an appreciation of a wide range of subjects and techniques, thereby preventing myself from becoming totally irrelevant. And as the saying goes – if I can do it, anyone can.
If you identify as an “ABAP programmer” and fit into the single-language category I’ve described, you have an exciting journey ahead of you. What’s more, if we really dig into what we think about when we say “ABAP”, you’re already on the journey; ABAP isn’t really a single language anyway – there’s SQL, dynpro logic and even the declarative language one uses implicitly in the data dictionary.
Rather than identify with a single language, it might help to identify as a developer of solutions, where the canvas, tools and colour palette is fluid, but what remains constant is your ability to be creative, and to express yourself, combining multiple moving parts into a single piece of art that is worthy of a long gaze and also gets the job done. Beyond that, it will re-educate those that consider you merely a machine that turns coffee and specifications into executable code.
So what are you waiting for? Pick something that seems interesting, and dive in. If you were to ask me for a suggestion, I’d say CDS. It’s close to where you feel comfortable already, almost the next ring out from your centre of gravity, and it’s a critical piece of today and tomorrow’s solution set in the SAP world. But if there’s something else entirely that you’ve been wondering about, grab it and go. These days, in the increasingly open world of SAP enterprise software development, it’s more likely that you’ll be able to directly use what you learned in your day job as a developer.
This post was brought to you by Pact Coffee’s Umurage Mbazi (I still have some beans left from last Monday), the gentle warmth and brightness of a promising Bank Holiday Monday here in England and a pleasant browse through my battered copy of The Thames and Hudson Dictionary of Art and Artists.
Read more posts in this series here: Monday morning thoughts.
Great post, yet again!
Reminds me of a time when I was interviewed by a consultancy firms (one of the big ones) when I was at Uni. My degree was physics and French, but I was interested in development and writing code. I was asked did I see a parallel in speaking multiple languages and writing code. At the time I think I didn't see one, all the programming languages I had used seemed to be based around a very English based vocab and really once you've built a for loop in one language, the next is pretty much the same. So to swap around coding languages was much simpler than speaking another language with a level of fluency that those you were speaking to did not know you were British. I told as much to the interviewer who was possibly a little surprised, after all I was supposed to be making the case that they should hire me and not a CS grad....
What, I realise now, is that what I learnt in speaking another language was to be fluid in the way I thought about approaching a concept/problem. Not to just translate it directly into the way that I always speak and then back again. This then applies directly to development over coding. The biggest thing is to learn and pick up new ways of thinking, find a different approach to solving the same problem, reimagining the problem in a completely different way.
Being a good developer is something to be proud of, and it's definitely not just about being able to code.
Thanks for continuing this series and loving this particular topic!
Cheers,
Chris
Thanks Chris for a great comment. Yes, I think you’re spot on. It’s not about the syntax and grammar of a given language (spoken or programmed), it’s the way you learn to *think* in that language. Moreover, the sometimes strong differences in languages make you think in completely different ways. One obvious and present-day example for me is of course how learning about functional programming in general, and looking at different functional languages like Haskell and Elm in particular, have given me new perspectives and ways to approach problems and solutions. I explored Haskell, Elm and other languages in this talk I gave at Lambda Lounge at Manchester’s MadLab last year:
Discovering the beauty of recursion and pattern matching
where the differences in thinking were significant. Going further to other paradigms (for example with array-based programming with APL, or logic programming with Prolog) one finds even greater differences.
For what it’s worth, I too studied language at school and university. My degree is in Classics, i.e. Ancient Greek and Latin, and I also took modules in Sanskrit and philology (perhaps the ultimate subject for lovers of language, quite literally!).
Mmmmm..... You've written about a quandary I've been having lately. I used to and still do sometimes jump up and down and yell - we are not JUST developers.
So in my mind to be a good developer, you need to know the language. To be a great developer you must know the requirements, be able to understand the basics of how it fits into the big picture, and know what would be a good functional test. (Now add have at least a basic understand on what is the best language to use. Or use "ABAP" (there are many different types of ABAP)
So here's the paragraph that jumps out to me:
Rather than identify with a single language, it might help to identify as a developer of solutions, where the canvas, tools and colour palette is fluid, but what remains constant is your ability to be creative, and to express yourself, combining multiple moving parts into a single piece of art that is worthy of a long gaze and also gets the job done. Beyond that, it will re-educate those that consider you merely a machine that turns coffee and specifications into executable code.
Now here's the problem with my old thinking. The more I learn in different language, the more I have to struggle to keep up with the functionality. So as you have written, staying with "ABAP" not really a language would help me have the time to understand more of the functional side.
If I try to learn some of the new languages that are widely available, that gives me less time to understand the functional/configuration side of SAP.
So my head starts spinning. Then I think about that time when I had to learn ABAP. I had to pick up the functional side by what projects I was on. So it was slow on both sides. At this point can I afford to be slow on both sides?
At one point I was asked - what do you want to do functional or technical? At that point I said easily - both. So my quandary is not whether to stay "only" programming in ABAP. (I can't by the way in a small shop) I have to learn some new languages to work on the projects that need them. My quandary is how to do everything at once. Yes, I will limit myself to only a couple languages at a time. But I know I will be slower. Me - frustrated. I really do have to know something about the functional side or I won't develop the correct thing. Me - frustrated again. (Small shop again I will need to pick up both. Not that I don't like that.) Sigh. I think technical or functional. I used to have an easy answer. I think that answer is getting harder everyday. As always, I'll try to be both. Meaning I will never be the best at either. <Sigh>
Yes, as I walk through all the programming knowledge I have in the cob webs of my brain, I think they all have the same basic structure. Wait! Objects vs. structural. OK a little different. AHHHHH!
Your Monday thoughts have me driving in a circle. (Infinite loop) Oh well, as always it will be a great journey. As you pointed out - there will be many different ways to deliver on a project. So if you are JUST a developer, you still have fun options to pick from. There is no such thing as an ABAP developer. Even if you identify as one. There are many different flavors of "ABAP". Also, You will know more than development - I'm sure of it!
Happy Monday!
Michelle
Great thoughts as always, thanks Michelle.
You're not along in your struggles. I recognise all too well the challenge of the "narrow, deep and fast" vs "broad, shallow and slow" modes of progress. But one thing I told myself early on is that above all, being a developer is subjecting oneself to constant change and growth.
If I'm feeling glib, my answer to the innocent question "what do you do [for work]?" is "I learn [and then apply that learning]". A natural consequence of this is that I find myself oscillating between both modes of progress. With the changes that we're seeing as SAP continues to embrace the cloud, I'm in "broad, shallow and slow" as I've set myself a wide spectrum of topics to embrace. But that's also OK. Of course, as you intimate, it has to fit the constraints of the "day job", but that's then down to me, as it has been all my working life.
So two deliberately provocative thoughts upon which to end this reply:
Totally agree. I really didn't hear the "JUST" in the blog. But I heard it in ABAP Developer. That's not all a persons does. An ABAP Developer does a whole lot. So for those of you that say that - you are selling yourself short.
Yes - that is key. Learn and change.
My first post-graduation job was in the IT department of what was then the newly privatised British Gas circa 1990. There, we were trained to be analyst programmers. That meant talking to the end-users, developing specifications, developing programs, testing, user acceptance etc.
I got into SAP around 1996, and I was still talking to the endusers. I didn't encounter the "just a coder" mentality until I was involved in projects where there were consultancy partners. Funnily enough, while there were consultants "assisting" throughout most of the project processes, the one area where they didn't really have any involvement was development - especially in later years.
I came up with a theory. Consultancies don't like to produce anything concrete. They do like to produce lots of paper. They don't like specialists, they do like generalist. It's a lot easier to hide the incompetence of some consultants in areas like spec writing, than it is to hide a program that doesn't do what it was supposed to do or breaks every five minutes. Consultancies therefore did everything except the programming to increase billable days without increasing responsibility. Coupled with a "once the project is over we're out of here" mentality, it's great for consultancies, not so good for end clients.
Of course, once you've split off development from the main project processes, you can start thinking that programming doesn't really require much skill, and one programmer is the same as another. It must be that way, otherwise you'd find consultancies offering to sell these skills. And when they do, they're half the price of a functional analyst, so really can't be worth much anyway. Let's outsource.
As a result you find fewer able, imaginitive developers in the SAP world. The creatives go somewhere where they can be better appreciated... and be paid better.
Anyway...
Back in 2003, I did some management training courses provided by my employer. Much fun in the Jura mountains, enjoying time and wine with fellow young first-line managers. We were all given a Myers-Briggs typing analysis, which tries to put define your personality in general terms, within four categories.
From myersbrigg.org
Favorite world: Do you prefer to focus on the outer world or on your own inner world? This is called Extraversion (E) or Introversion (I).
Information: Do you prefer to focus on the basic information you take in or do you prefer to interpret and add meaning? This is called Sensing (S) or Intuition (N).
Decisions: When making decisions, do you prefer to first look at logic and consistency or first look at the people and special circumstances? This is called Thinking (T) or Feeling (F).
Structure: In dealing with the outside world, do you prefer to get things decided or do you prefer to stay open to new information and options? This is called Judging (J) or Perceiving (P).
I doesn't mean that if you make decisions as a Thinker, you can't learn to make decisions as a Feeler - it's about preferences.
When I took the test, I turned out to be an INFP. Introversion, Intuition, Feeling, Perceiving. The test administrators were surprised to discover that I had been working most of my life as a developer. Developers were supposed to be INTJ. My Type Indicators were expected from people in creative careers such as writers.
Over the next few years, as I was running reasonably large development teams, I unscientifically got the developers to find out their Type Indicators, using online tests. What I found was that around 90% of my teams were classic INTJ. However, 10% were, like me INFP.
What was interesting is that the this 10% were the people that the functional analysts seemed to prefer working with. They were also the people whose code was better designed, more robust, easier to understand, easier to fix. They also tend to be the people who are more likely to try out new techniques and technlogies.
By the way, I know many INTJ programmers who are absolutely brilliant - I'm not dissing them! This is about tendencies and trends, and I recognise that being of this particular type, I may perhaps have an inbuilt bias!
I think your comments about artistry are particularly applicable to the 10%.
I program readily in Javascript, Java and ABAP. I've been paid to develop in many other languages during my career.
Thanks Matthew for these great insights. I particularly liked the way you expressed your thoughts about consultancies - it made me smile. Also, the story you recounted, about development being seen as the low skill "last mile" that could be done by anyone anywhere resonates with me too, and has been presenting challenges for a good while now.
I mentioned that the thoughts behind this particular post were triggered by something I heard in a Kevlin Henney talk. In that same talk, or another one I watched, he made the point that the "software production" process was the last 0.01% of the effort - and is merely represented by copying source code or other artifacts. The rest of the effort is in the creation process, and that's where we get down to what developers really do.
Incidentally, I picked up in your comment an implicit contrast between a "developer" and someone in a "creative career" such as a "writer", and this struck me as interesting, as I'd class "developer" firmly within the "creative career" category alongside writers.
Really fascinating points about Myers Briggs. I'm not sure I'm entirely convinced about the system, but what you recount makes sense. I certainly understand some of the identifiers.
Incidentally, at an SAP Inside Track event in the Netherlands way back when, the inimitable Thorsten Franz once explained to us that an introvert is not someone who is shy, but someone who recharges alone (as opposed to in crowds). That has had such an impact on the way I act, and has helped me to know myself better, and not feel "guilty" any more about disappearing early from parties or other gatherings.
I agree with Thorsten.
In my spare time (hah!) I'm involved with amateur theatre. As an actor, I've learned how to pretend to be extrovert. This comes in useful when you're directing and dealing with a team of fifty or more actors and crew. It's also useful in day to day life and work. I can give presentations on any subject with minimal preparation if I have to, and appear confident and knowledgeable.
People who meet me find it hard to believe that by nature, I'm introverted! After I've been extrovert for a while, I have to retreat somewhere quiet! 🙂
Concerning developers and writers - yes, there is a huge amount of creativity in both. Perhaps it is fair to say though that the majority of ...er... coders around the SAP world today are not terribly creative and rarely show initiative - regardless of their MBTI scores!
Totally enjoyed your comment. I say it time and again "developing programs is as much an art as it is a science!"
From an INFJ.
Great post!
I've come to consider coding to be a literary activity in which the writer intentionally expresses concepts using the vocabulary and grammar of the language(s) available to them.
Knowing a grammar and commanding a vocabulary are not sufficient to achieve a literary or programming masterpiece.
This is a point made very well indeed. There are multiple levels of literacy, starting from, as you say, the basic knowledge of grammar and vocabulary, but that's only the start. Expressiveness and meaning (and solutions) can only start when one gains the ability to express oneself, using the concepts and facilities afforded by the language in question ... and those concepts and facilities can differ greatly from language to language.
Here's an example. After watching this particular video many many times, I'm still happily amazed at how ideas, concepts and solutions are expressed in APL - it feels so foreign, but at the same time I have just enough understanding to be struck by a sense of wonder and appreciation:
A Sudoku Solver in APL