About Markus Sprunck

Markus Sprunck works as senior software engineer and technical lead. In his free time he maintains the site Software Engineering Candies and experiments with different technologies and development paradigms.

Top 10 Things Every Software Engineer Should Know

Please take a second to look at our brand new Java Resource Collection.

The following top ten list collects some important things I have learned in the last eighteen years as IT professional. It is a very personal selection and doesn’t necessarily reflect the opinion of a software engineering organisation.

There is no strict ranking in the list – though I tried to put the more important things to the top.The technical and business know-how is more important for young software engineers and the soft skills getting increasingly relevant for senior software engineers.

1) Fundamentals of Emotional Intelligence

Almost all of us work with a lot of people. In my first year after university, I had the opportunity to work on a clear big task without any customer and the need to talk a lot with peers. It was pure haven! Just do a complex task and have fun with the compiler. Later the trouble started with more complex tasks, increasing responsibilities and the need to work with people I didn’t liked at all.

During my professional life, I attended some so called soft skill courses. In these lesions I learned a lot about communication techniques, negotiation strategies and team dynamics. All this have been mechanical tools or psychological theories. Good to know, but the concept of Emotional Intelligence is something different.

The Wikipedia definition of Emotional intelligence starts with the sentence “Emotional intelligence (EI) is the ability to identify, assess, and control the emotions of oneself, of others, and of groups.” [1] The important key word in this sentence is emotions. Emotional intelligencedescribes the role of emotions in our lives.

Some years ago, I attended a project meeting with some senior management and the boss of my boss said something to me which sounded like “Hey Markus, you forgot to give me the information XYZ in time!”. I felt embarrassed, like a culprit and explained him that he was not right. The result was that I won the discussion with him and form that day I lost an important supporter in the company. My reaction was stupid and worthless.

Yes, I won one battle, but lost the war.
The root cause of this disaster was an automatic reaction on my site and a reciprocal effect between this senior management guy and me. With better sens of self and self-regulation, I would have been able to manage the situation in a better way.

If you leave sometimes a meeting and say to your self “Oh shit! Why did I say this?”, maybe it would be a good idea to learn something about Emotional Intelligence and yourself.
My favorite breakdown of emotional intelligence is:

  • Intrapersonal intelligence describes the ability to have positive relationships and/or good communication between people. This means that you understand what people fell and need. The key competences of intrapersonal intelligence are:
    • Sense of Self:
      – recognize the own feelings, emotions and reactions
      – mindfulness to get a better awareness
    • Self-regulation
      – controlling the current inner state
      – bring own automatic reactions to mind and interrupt
    • Personal leadership
      – know and lead the parts of your own personalty
      – care about own strengths and weaknesses

  • Interpersonal intelligence describes the introspective and self-reflective capacities. Know your self, your emotions and what your weaknesses or strengths are, being able to control your own reactions. The key competences of interpersonal intelligence are:
    • Empathy
      – recognize the feelings and emotions of others
      – express sympathy in anappropriate way

    • Reduction of Automatic Reciprocal Effects
      – bring automatic reactionswith othersto mind and interrupt (if needed)
    • Creating Relationships
      – create mid- and long-term relations with others

2) Understand the Business of your Customer

How can you design and implement good software without deep understanding of the purpose or use? The answer is easy: “If you don’t know the WHAT, you can’t decide about the HOW.” A deep understanding of your customer’s and/or users’sbusinesswill lead tobetter requirements, designs, implementations and tests.Most of the software’s functionality creates no business value. The challenge is to select the functionality which creates business value. The better you know the business the higher is the probability to implement the best system.

3) Minimum One Programming Language for each Mainstream Development Paradigm

The discussion what is the best programming language has a religious character, it’s more a question of belief. I don’t like to preach my personal belief about the bestlanguageshere, but one thing is important: “Learn more programming languages, at least one for each mainstream development paradigms.”

  • procedural programming languages (C, COBOL, PL/I, FORTAN, etc.)
  • object-oriented programming languages (Smalltalk, Java, C++, etc.)
  • functional programming languages (Erlang, Clojure, F#, etc.)
  • declarative programming languages(SQL, XSLT, regular expressions, etc.)

Its a good idea to know at least one multi-paradigm programming languages like Python, Java, C++ or C#. You find many listsof programming languages by type or other categoriesin the web [2].
Dependent of your industry, personal preferences and daily tasks you should select your individual top 1o list of programming languages. Learn them and try to use at least 3 of them on a regular base. The old saying “If your only tool is a hammer, all your problems will look like nails” is particularly true for development paradigms.

4) Know your Tools

There is a huge number of tools specializing indifferent disciplines like: requirements management, software & database design, software configuration management, build & deploy, continuous integration, development, debugging, profiling, code analysis or testing.

It should be mentioned that specialist from infrastructure/operations have also toolboxes with interesting capabilities, e.g. network monitoring, network analysis, operation system analytics, penetration testing, log file analysis, database performance tuning.

A software engineer can’t know all tools in detail, but he/she should know the key concepts and underlying technologies. Knowing the right tool and how to use can increase the productivity and quality.Spend some time to learn about tools.

5) Standard Data Structures, Algorithms and Big-O-Notation

When I stated to develop software it was absolutely necessary to know a lot about data structures and algorithms. The reason for that was the missing availability of standard implementations. Today most languages have comprehensive libraries for container, sorting and other operations.
Still it makes sense to know more. There are two main reasons:

  • correct use of the standard libraries and
  • some times you need individual solutions.

You should be able to analyse your own or others code. TheBig-O-Notation is the standard method to describe the expected consumption of time or memory depending from the number of data. [3]

If a manual analysis is to difficult, just make a micro benchmark and measure with test data of different size. Draw it in a plot and find a good fit of a possible model function. This is always better than nothing.

6) Don’t Trust Code without Adequate Test

Ten years ago, I trusted my code. Why not? After 8 years C++ with excellent skills and a lot of experiences. I just coded, tested and everything was working well. But over the years I made and saw a lot of errors. Because of these errors, I lost the trust in my own and others code.

Today, I don’t trust code until it passed:

  • unit test,
  • integration & system tests,
  • checks of performance and memory with real world data,
  • static code analysis,
  • measure code coverage of test,
  • load & stress tests and
  • peer review.

This sounds over engineered, but you have to spend the time either during development or during maintenance. I favor to do the work once with good quality and not to spend my time withtroubleshooting.

7) Basics of Project Management, Lean Management and Agile Concepts

Even you don’t like to work as a project manager, you work in teams and at least have to organize your own work. To get along with technical leads you should understand their wording and way of thinking. Today everybody can work as project manager, scrum master or technical lead. Spend time to learn about management, because sometimes you should manage these guys.

A good example is effort estimation. My personal experiences say, that if you ask a software engineer about the effort of a task you get in 80% of the cases a dramatic underestimation of the effort. A software engineer tends to estimate just the good case without unexpected problems. This causes delays and/or poor quality because quite often the unexpected problems just happen.An other problem is the Definition of Done. The project manger means everything is done and often the developer estimates just the technical stuff.

Last week I had such a case. The developer estimated just one week of work. And after a complete planning, we saw several months effort. The developer estimated the time for implementation and forgot to estimate documentation, security concept, data protection issues, alignment with workers councils, reviews, project management efforts, deployment, etc.

8) Key Metrics of Software Development

Know what happens in your software, process, team and your own work. It is very difficult to control something what you can’t count. I encourage you to have question and try to find a real world measure as answer. Then you can have target values, do your work and find out if it worked out. Important is the word “real world measure”.

In software engineering we find a lot of obscure measures and/or derived metrics. E.g. the so calledmaintainability index (MI) [4]:

MI = 171 – 5.2 x ln(avgHV) – 0.23 x avgCC(g‘) – 16.2 x ln (avgLOC) + 50 x sin (sqrt(2.4 x perCM))

where HV is the Halstead Volume, CC is the Cyclomatic Complexity, LOC is the lines of code and perCM is the percentage of comment lines. This is not what I call a real world measure and I don’t understand this.

My advice is easy: “Never use a measure and/or metric you don’t understand 100%. Some times it is enough to take some glasnuggets and count them (see also How Lean IT helps to reduce waste due to interruptions in software development?).”

9) The Root Cause of the Last Defect

Maybe your last error was not as severe, but to learn more about the root cause and negative effects   you should analyse it.

  • What was the root cause?
  • In what development phase came the error in the software?
  • How could it be detected earlier?
  • Would a tool help to avoid it?
  • Would a rule help to avoid it?
  • Was it a qualification problem?
  • Is the working environment (lot of interruptions, etc.) the root cause?
  • Is it an documentation problem? Or maybe a communication problem?
  • What are the costs to fix it?
  • Are in the affected component more errors?
  • Are the test cases good/complete enough?

You see a lot of question and the list is still not complete. The most important point is, to find the root cause to get better over the time. This works for your own qualification and way of working. And it works for your team. You just have to ask some question.

10) Understand the Infrastructure

I spend the my first 10 years in IT without thinking more than a minute about infrastructure. It was not necessary, because I didn’t work in an enterprise environment. At the moment I work for a bank (sorry for these Lehman Brothers stocks, nobody asked me). In a bank you have a lot of these infrastructure people. They are really different form software engineers. But, I don’t like to discuss here the differences and possibilities to get along with them.

Important is their language. Infrastructure peoples talk in “Information Technology Infrastructure Library (ITIL)”. Spend at least some days to learn this ITIL terminolgy. [5]Some terms are completely different uses as developers do.

The second important thing is, that in infrastructurethe people are much more specialized than developers. Sometimes a developer has just one question and needs five infrastructure guys for the answer. The ITIL stuff is maybe the glue between the people ininfrastructure.

Further Reading

Reference: Top 10 Things Every Software Engineer Should Know from our JCG partner Markus Sprunck at the Software Engineering Candies blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

11 Responses to "Top 10 Things Every Software Engineer Should Know"

  1. devsoft says:

    i’m not offensive here, just want honestly express my thought. 
    i been serious in software development since later 2008, and have read dozen of article ranging from software development, design, web to icon design, i often saw knowledge and experience ppl like you who write article about something like “top ten u should know as [job title]“, “top ten mistake u should avoid when freelancing”, “what u should know functional programming” and etc, do u as a author really do the way as u write like u really know and experience using each mainstream development paradigms in ur day to day workflow and use in production product?

    thx

    • Markus Sprunck says:

      “Do u as a author really do the way as u write like u really know and experience using each mainstream development paradigms in ur day to day workflow and use in production product?”

      This is a good question. To be honest – I try to “walk the talk”, but I’m not perfect. This is the reason why the title of the article includes the word ‘should’. 

      Two areas where I’m not able to reach my own targets:

      1) The topic ‘Minimum One Programming Language for each Mainstream Development Paradigm’ is a field where I have weaknesses. It is just to time counsuming for me to be up to date in each filed. Without constant practice its very difficult to to keep the know-how, because constant practice would be  neccessary. I have three children and a job as technical lead (lot of administrative stuff and meetings), so my only chance is to spend some hours in the evening to lean and practice. 

      2) Also ‘Fundamentals of Emotional Intelligence’ is difficult for me. It is more a constant learning process for me. Just ask my wife.

  2. Lucb1e says:

    Is there something wrong with your spacebar? For example in the last two sentences you missed 3 spaces.

    • Markus Sprunck says:

      Sorry for the missing spaces. This seems to be a technical problem during copy of the content form my original blog. The poor grammar, spelling and all other errors are my fault. Please, give me feedback what can be improved (sprunck.markus at googlemail.com). 

  3. khal2012 says:

    Interested in your reference to the Maintainability Index – the formula looks pretty obscure but, as the article you link to points out, it is one of the few metrics to be validated against real world software projects. 

    Your basic premise is correct though – we don’t manage the software process by fact – we need to measure more, to understand what we are measuring and to understand how we should react to changes in those measurements. Measurement fits well in the Agile process in that it works best in a well-defined iterative process.

  4. Great article. Impressive is that you have correctly captured the very important part of career, relationship and human life, that is Emotional and Interpersonal Intelligence. It is always important to be aware of one’s own emotions, personality while “trying” to understand other person’s ideas, intentions, emotions and synergize to interpersonal collaboration.

    One constructive feedback I would extend that some places I have noticed spelling mistakes which felt like rough areas on the silk sheet, may be you proof read your “thoughtful” blog post ( yourself or through another person ) before publishing could help to enhance the effect. Thanks and Best Wishes.

    • Markus Sprunck says:

      Many thanks for your feedback. English is not my native languages – this is no excuse. So I’m grateful for every hint where my typical errors are. Especially my grammar is still not good. If you have proposals of how to formulate a sentence in a better way or where I have spelling mistakes, please give me a hint. You can send me a e-mail (sprunck.markus at googlemail.com). 

  5. Really this is an informative and helpful post for software
    engineers. Software development is the big professional field at this time and
    it is so popular. I agree with you that a software engineer always should be
    wary to every problem.  He has such type capacity
    that he understands easily his customer’s problem and put the positive result.  A software engineer should be a good management.

    I think your article definitely will be useful for all
    users.  
     

  6. LaurenSmith2 says:

    Great example on estimation when working in teams or with manager. Thanks for sharing your ideas. Reminds  me of an excellent book I just read by John R. Fox entitled, Digital Work in an Analog World: Improving Software Engineering Through Applied Psychology. The author writes about how the non-technical aspects of software engineering are vital and not to be overlooked. It’s a wonderful resource for all software developers. Here’s the author’s website: http://www.analogdevelopment.com/

  7. Karthick S says:

    Excellent article! I have decided to read this once a week till it is entrenched in my mind. This deserves the time.

  8. internet says:

    For example, you may write several articles for Associated Content that are
    related to each other. Many companies also offer to train people under their SEO reseller programs to help them get more companies looking for SEO assistance
    and earn a better commission at the same time but before you join any program make sure to join an SEO firm that is
    going to compensate you well for the business you will
    be bringing for the firm. The features of the greatest SEO agency will be characterised in this
    form of method which they provide the top work in the internet search engine optimizer.

Leave a Reply


3 − one =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close