3 tips for an (SAP) developer based on your experience
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:
- 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.
- 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…
- 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
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.
Simple is usually the best (see p. 2). We all know that complexity is bad. Very, very bad.
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.
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.
i second this! 👍
"Nothing is more permanent than a temporary solution." 🙂
Funny thing, I've never done these things. Except the TDD course.
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 🙂
Someone fears prose and lyric, hidden in comments 🤣
I rarely add comments to my code.
is replaced by
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.
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.
Comments exist for complicated algorithms and to indicate really important information.
doesn't just not add value - it detracts value. You're into negative value...
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.
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 😉
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.
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
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.
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...
and that's precisely why I add lots of comments 😀
Andrea the goldfish.
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! 😁
Are we in yet another "comment/no comment" war? please say yes!
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..
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:
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
More tips from Twitter:
I had the same idea to add John Patterson's tips here but I was too slow 😅 As always: Many thanks for your support.
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.
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.
I especially like number 3. Timeless classic!
F5? You're still using SAP Gui?
At which point a small fight broke out 😀
Okay, maybe 3 includes 2 recommendations.. hope it's still ok 😀
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.
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 🙂
4) Hardest to master 😉
5) Best humor!
Not all of these are completely new to this conversation, but here's my spin on them:
+1 point for creativity 😉
Meh. It's an old joke.
if you hadn't done it, I would have posted it... 😂
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
1. Learn Clean Code;
2. Learn Clean Architecture;
3. Learn Design Patterns;