3 tips for an (SAP) developer based on your experience

[Michael_Keller]

Dear community, let's create something valuable and helpful together. Every day we make our experiences (as developers). With software, hardware, processes, organizations and especially with people and ourselves. Some experiences are planned, others come as a surprise 😂 Over time, a real treasure of experiences accumulates.

It's precisely this treasure that I consider to be extremely valuable today. Experience often decides whether something goes well or bad, whether a situation can be mastered or not.

That's exactly why I came up with the idea for this SAP Community blog. Please write your three most important tips in the comments, based on your developer experiences. Tips you want to give to other developers, young or old, experienced or inexperienced, in the SAP universe or not.

I know "three" is a very small number. The choice is very hard. To make it even more challenging: choose the tips at a very high level 😊 Hopefully the tips will apply to many areas of our developer life. However, it is also risky to set it too high. Oh, and it doesn't necessarily have to be SAP development related.

So here are my three tips:

1. Be data-centric: Focus first on the data, its meaning, structure and relationships. Understand them in the context of processes, organizations and IT. The algorithms then often arise by themselves.


2. Software development is not purely an end in itself: Software is made by people for people. So just connect with everyone. Listen, observe, speak your mind, discuss, understand, ask questions, be helpful and more. This is the beginning of so many things...


3. Be "well organized": I've seen a lot of good developers, but unfortunately I couldn't rely on them at all. In our modern, highly networked world, in which many people are involved in the development, maintenance, operation and use of software, good self-organization is simply a basic requirement for working together.

What are your three tips? Please write a comment. And feel free to refer to this blog on Twitter, LinkedIn and other social media so that others can contribute their tips.

 

Best regards, thanks for your participation and stay healthy

Michael

[Jelena]

FIRST! 🙂

My 3 tips.

1.80% of success is showing up (c) Woody Allen

It doesn’t mean showing up physically, especially these days. It means be present, be engaged. Participate, ask questions, take initiative. Before you know it, you are The Expert simply because no one else showed up.

2. Always do your best

Picture says it all. Print it out, put it on the wall. Make it your desktop wallpaper.

3. KISS

Simple is usually the best (see p. 2). We all know that complexity is bad. Very, very bad.

[Michael_Keller]

Nice and above all FIRST post! 😅

By the way, complexity fails really quickly. For example under time pressure, IT resource bottlenecks, a lack of know-how, sufficient staff and much more. This is exactly why the KISS principle and its application are so valuable.

[david_joseph]

My tips are:

1) Focus on code quality : make it a practise to self review and unit test as a daily signoff activity. If done as a routine, even the most complex code will adhere to the highest quality standards organically.

2) Get enough functional know-how to enable you to correctly separate the application/requirements into simpler blocks. Analyse with different types of data to get a grasp on scenarios. Create or ask for varied test data during analysis.

3) Avoid waiting till the development is 100 percent complete to showcase it to stakeholders. It is better to show and get inputs from stakeholders frequently. This helps us to correct our roadmap based on received inputs.

 

Hope it helps.

[former_member765580]

1. Know the theory - mostly from SAP official documentation (SAP has improved a lot in this area), and SAP blogs (fantastic tool to gain SAP knowledge and SAP wisdom)


2. Practice, practice, and practice the theory in (1)


3. Share your knowledge - this is how you really grow and cement your knowledge

[matt]

1. KISS


2. SOLID


3. Do it right first time - don't take shortcuts, they'll come and bite you at some point.

[jpsapabap21]

1. Learn to get opportunities - never say I did not get chance to work on this, so I don't know. Use SAP trial accounts, open sap courses, SAP developers tutorials to learn.


2. Share your knowledge - it helps you the most


3. Do the certifications with hands-on practice.

[jenifer_sam]

1. Take time to understand the functionality before jumping to writing x lines of code. Most often, understanding the backlog helps you write lesser lines of code.


2. Write readable code with comments


3. Experience sharing - the best way to learn and grow

[hardyp180]

1. If at all possible sit with the end users who use your software. Not very practical if you work offshore, but in that case maybe lots of screen shares with the end users. Developers cannot sit in a vacuum. If you know what happens at the coal face you will be ten times the developer you would be otherwise.


2. Spend some time each week learning new things, even if you spend an hour a week that puts you above 99% of other developers. There are a load of free online learning courses now, and conferences, so why not?


3. Automated Unit Tests. It is a GIGANTIC effort but if you come out of the other side you will be ever so glad you did this.

I happened to be on TEAMS to one of our business analysts and so asked her to give me three tips for new business analysts. She said:

1. Document the complete design of a solution


2. Document the complete design of a solution


3. Document the complete design of a solution

And that includes Issues and Resolutions.

I waste so much time asking everyone- what did you do

or how is this supposed to work

if only big business realised the importance of documentation - they would save $$$$$$

the long term gain is a cost saving without question

Cheersy Cheers

Paul

[abo]

One quick note on comments: they should explain the reasons for doing something, NOT the how unless that is incredibly complex. We can read the code, we can't (yet) read the mind 🙂

[Jelena]

More tips from Twitter:

[hugo_degroot2]

1. Complexity is bad. Very, very, very bad.


2. To design is not to decide what features you put into a product; it's to decide which features you leave out.


3. There is never time to do it right. But, paradoxically, it seems there is always time to do it over!

[rgore]

1. Google - Find answers or hints to all your questions


2. Debug - Single Step Debugging(F5)


3. Debug again

[Michael_Keller]

Someone fears prose and lyric, hidden in comments 🤣

[Michael_Keller]

I had the same idea to add John Patterson's tips here but I was too slow 😅 As always: Many thanks for your support.

[Michael_Keller]

I especially like number 3. Timeless classic!

[Florian]

1. Don't stay in your bubble - Challenge yourself every now and then with tasks you aren't good at


2. Don't stay in one language - That doesn't include to do 5, but at least 2 which are more than a basic user


3. be curious - always look around you, sneak peak in other ecosystems and make your careerpath.. don't let other do that for you

Okay, maybe 3 includes 2 recommendations.. hope it's still ok 😄

[Florian]

Don't agree to comments. if the code is well organized and structured.. why is there a need for a comment... if you want to comment anything use the documentation and put whatever you have to say to the customizing.

If you have valid arguments, except those people before us didn't orgnized the code, that's why you see a need for a comment, then I would love to see a blog post why you are thinking that way.

Ready to discuss it over there 😉

 

[Thorsten_Franz]

1. Explore how things work. Start with the F1 help on a dynpro field, do the where-used to find the customizing table, find the view cluster or IMG node to identify related customizing tables, and do where-used on those to find the code that interprets the customizing. You’ll understand how stuff works and what the possibilities and limitations of the system are.

2. Experiment and play. Try things out in the small before you build a crystal palace and your assumptions. If you’ve found an SAP-provided API, write a small Z report and call it in a few different constellations before you go to the trouble of wrapping it in a complex OData service with multiple entities. Make your way from smallest executable program to full-blown completion of your task via many intermediate steps, each of which is testable and allows you to see exactly what is working and what isn’t.

You’ll learn along the way and discard old assumptions. Your design will be much better then it would have been without the intermediate experimental stages.

3. Tip generously. Many SAP professionals do a lot of business travel, stay in hotels and eat in restaurants. Create some good vibes by appreciating the work of others with decent tips. Karma will find a way to repay you and the community of SAP professionals.

4. Don’t get thrown off by sudden context changes. Customers will do that to you.

 

 

[hardyp180]

I would say comments saying WHY the code is the way it is, as opposed to what it does can avoid the "endless circle" problem.

That is you code something in what appears to be the most logical, elegant way you can and it does not work as well as you hoped due to performance problems or any of ten billion other reasons.

I would comment it thus - I wanted to do XYZ but I ended up doing ABC because XYZ did not work and here is why, if you can find a way round that problem go for it.

With no comment all the next programmer will presume you were an idiot, and then change the code back to the obvious solution, get the original problem again, the end users complain, the programmer change sit back, makes no comment in the code as to why they reverted the code, and then six months later the next programmer comes along, and the cycle repeats forever.

[gabmarian]

Agree.

For example, recently I wrote an HTTP service where I had to do some counter-intuitive coding tweak to conform with the UI application.

So I wrote something like:

// this was needed for proper client side message processing. see <github_issue_link> for details

[gabmarian]

Another example where comments can be useful to describe dependencies between seemingly unrelated objects.

Let say you have a custom ABAP program that calls up a BAPI, which has its own user exit. Your program needs the user exit to work properly.

In this case the

" This program depends on <user_exit>

can be extremely helpful for later maintenance.

[gabmarian]

"Nothing is more permanent than a temporary solution." 🙂

[ChristianGünter]

1) Know what problem you're solving. Don't hesitate to clarify and challenge vague and ambigious requirements.

2) Shorten feedback loops. Get fast feedback from your code with (unit-)tests, test programs, etc. and from your customers/users.

3) Improve one small bit every day. Over time the magic of compounding will deliver extraordinary results.

4) Learn to say no.

5) Always over deliver. E.g. when somebody asks you for three tips deliver five 🙂

[afordham]

Not all of these are completely new to this conversation, but here's my spin on them:

1. Try using the newest technical approach to deliver the solution (e.g. CDS/RAP vs. hand-crafted DPC_EXT) - you're never going to learn it otherwise.  There's no need to broadcast this fact though, as people who don't understand will just panic.  Your fellow, less forward thinking colleagues are also not going to drag themselves into the 21st century unless they're forced to make a change to something written outside of their comfort zone
2. Don't bother with header/change control comment boxes on every bit of code (especially methods) until at least after go-live.  No one cares about the transport request number, the date you made the change, which functional consultant changed their minds about the design, which system test bug your change fixes, etc. etc.  If they really want that info, you can get it either from the change history, the transports or the functional specification.  There are few things more annoying than not being able to see the 15 lines of ABAP code when you first open the object because of the 50 lines of change control comments at the top
3. Challenge the functional design if it doesn't seem right - many functional consultants like to come up with the technical solution to their requirement ("Create a functional module called Z_xxxx...") because they think the year of ABAP they did back in the late '90s means they understand your job.  The continued placing of functional skills over technical skills is sadly still prevalent (just look at the salaries!), but don't let this influence your faith in your own abilities

[Michael_Keller]

4) Hardest to master 😉

5) Best humor!

[matt]

Funny thing, I've never done these things. Except the TDD course.

 

[matt]

I rarely add comments to my code.

* Do this

stuff...

more stuff...

things...

done...

is replaced by

do_this( ).

 

[matt]

 the next programmer will presume you were an idiot, 

Hi. My name is matt and I'm the next programmer. I'm a bad person...

[matt]

F5? You're still using SAP Gui?

 

At which point a small fight broke out 😀

[matt]

1. Use new things . Then, if they're daft, you can reject them with authority
2. Never tell everything you know
3.  

[abo]

and that's precisely why I add lots of comments 😄

Andrea the goldfish.

[matt]

Not quite what I was meaning to imply!

 

It's like defensive driving. Assume all other road users are suicidal morons and you'll be fine! 😁

[Michael_Keller]

+1 point for creativity 😉

[matt]

Meh. It's an old joke.

[former_member184876]

1. Keep it simple. Simplicity is more powerful than complexity.


2. Keep open mind. Ideas and suggestions can come from any side. Always keep open mind to change things for better.


3. Think in others perspective. Think like you are end user who uses your software. If you like/ do not like what you did, most probably the users do the same. So try to like and enjoy your software like an end user.

[ennowulff]

i second this! 👍

[ennowulff]

if you hadn't done it, I would have posted it... 😂

[custodio_deoliveira]

Are we in yet another "comment/no comment" war? please say yes!

[Florian]

Yes 😉 .. no, I know it's a discussion without an end... there is one side loving the comments for reasons, opposite don't like it and have vaild arguments and the truth is, it depends..

 

it depends, what people you are working with, how the team is organized and if you have a well grown organization...

 

so.. as mentioned before, if the next programmer will presume you were an idiot depends on all the above... some will think because of the comment, others because of not seeing a comment..

 

In my perfect small bubble there is no need for inline comments, because people know how to use the tool around and know where to seed information for the whole bunch of people..

[former_member38721]

bit late but still

1. talk about the tasks
depending on your surrounding there is a good chance to get vital input you have not thought of yet
If not, someone already mentioned google it

2. talk about the solution
might be interessting for others or even better for you, someone else will have inputs on how to do it even better next time
No-one to talk to? Write a blog

3. don't postpone monkey work
E.g., exception handling might not be the most exiting part when exploring a solution but it's even more boring reworking the whole code to incorporate exception handling

[mauriciolauffer]

1. Learn Clean Code;

2. Learn Clean Architecture;

3. Learn Design Patterns;

[jakob_straub]

1. Understand the requirement (and be able to test it)
2. Understand what you are doing (every line of code, you steal, you should understand)
3. Just do it (try everything out, learning is a process and if you can test your development trial and error is no problem)

[Maxx2]

John Patterson tips are fine EXCEPT -- IMO the first sentence in point number two is nonsense.  Your employer is EXACTLY who s/b paying for your further technical education.

 

If one has an employer not willing to provide additional training then it is time to look for another employer.

[Michael_Keller]

Hi. Good note. From my experience, that happened really seldom 🙁

At least in Germany there are too many companies that do not invest enough in the knowledge of their employees. On the other hand, there are too few employees that want to have new knowledge because change is bad and standing still is safety! 😉

Few employees switch jobs/positions and look actively for a better employer. But many moan about how bad everything is. It's a crazy and partly stupid situation.

In the meantime, however, I also see younger people who are much more advanced and are more likely to change jobs.

[Maxx2]

Commenting code is being professional to others and to your "future-self".  Leaving comments out has been the current fad for the past 20 years.  However, most code is not that well-orgranized nor structured, except maybe to the original author.

[matt]

I'm a fan of well placed comments, but VERY often, if you correctly modularise, you don't need them. My example was bad, let me try again.

* This bit of code determines the owner

...

  lots of code

...

* This bit of code works out the fullname of the owner

...

   lots of code

...

Replace with

owner = determine_owner( ).

get_fullname( owner ).

Comments exist for complicated algorithms and to indicate really important information.

* Determine owner

owner = determine_owner( ).

* Get owner's fullname

get_fullname( owner ).

doesn't just not add value - it detracts value. You're into negative value...

[Maxx2]

As an external consultant I put in lots of comments since what I have delivered will have to be maintained by others normally.  It is not just for the coders, but also the business experts to be able to understand what is/was meant to be done.  More often than not documentation is never done and when done never read.  When requirements change and the customer wants you or others back to change it an English description of what/when/why something was done is a professional service to others and a possible future you.  I consider it an add on/replacement to TDD for those who do not do TDD or those who cannot (i.e. functional-types) do TDD.