Core Values Of A Successful Software Engineer

Sometimes there is no TL;DR. A software engineer must experience and understand and iterate the process over and over again to realize the core values. There is no shortcut. Hard earned skills determine the future so we will not have any quick summary here.

Understands Quality

“Quality begins with the intent.” — W. Edwards Deming

  1. Validating the comprehensiveness of a requirements definition.
  2. Identifying software and system design objectives.
  3. Identifying quality control criteria as part of quality assurance.
  4. Identifying acceptance criteria for a software product.
  5. Establishing measures of quality characteristics in support of these activities.

Worships Computer Science Basics

“I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” — Linus Torvalds


A common developer does not need to understand hardware deeply compared to a kernel developer or embedded device programmer. But still understanding different types of computer memory (RAM, ROM), storage devices especially hard disk drives (HDD, SDD) and CPU processing and communication mechanisms would be useful when designing more complex solutions that implements algorithms for parallel and concurrent processing in multi-core CPU.

Data Structure

Choosing The Right Data Structure

  • Do you need random access?
  • Do you perform a lot of insertions? How about deletions?
  • Do you allow duplicates?
  • Are you searching for elements frequently?
  • Does your data need to be ordered?
  • Would you need to traverse the elements?
  • How big is your data?


A list of instructions for solving a problem. A set of mathematical instructions or rules that, especially if given to a computer, will help to calculate an answer to a problem. — General definitions.

P (Polynomial) Problems

P problems refer to problems where an algorithm would take a polynomial amount of time to solve, or where Big-O is a polynomial (i.e. O(1), O(n), O(n²), etc). These are problems that would be considered ‘easy’ to solve, and thus do not generally have immense run times. Many algorithms complete in polynomial time such as:

  • Testing for primacy
  • Hash table lookup, string operations, sorting problems
  • Shortest Path Algorithms; Dijkstra, Bellman-Ford, Floyd-Warshall
  • Linear and Binary Search Algorithms for a given set of numbers

NP (Non-deterministic Polynomial) Problems

NP problems were a little harder for me to understand, but I think this is what they are. In terms of solving a NP problem, the run-time would not be polynomial. It would be something like O(n!) or something much larger. However, this class of problems can be given a specific solution, and checking the solution would have a polynomial run-time. Integer Factorization and Graph Isomorphism are two examples of NP problems.

Standard Steps In Algorithms Development Process

  1. Problem definition
  2. Development of a model
  3. Specification of the algorithm
  4. Designing an algorithm
  5. Checking the correctness of the algorithm
  6. Analysis of algorithm
  7. Implementation of algorithm
  8. Program testing
  9. Documentation preparation

Embraces Agile As A Discipline

Remember, agile requires significantly greater discipline!

Writes Clean Code

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

Implements Test Driven Development(TDD)

“Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.” — Michael C. Feathers


Functions building blocks of any system. We have to take care of how we write our functions so that we can assure it’s functionality is always as expected, no supersizes and magics!

  • A function should do just one thing.
  • A function name should use descriptive names to accurately describe what it does.
  • A function should take fewer arguments. This also helps in designing the data structure.
  • A function should have no side effects. A function or expression is said to have a side effect if it modifies some state variable value outside its local environment, that is to say it has an observable effect besides returning a value to the invoker of the operation.
  • A function should not use flag arguments. A flag argument is a kind of function argument that tells the function to carry out a different operation depending on its value. Split method into several independent methods that can be called from the client without the flag.

Unit Test

A test that verifies the behavior of the smallest part of the system or component is a unit test. It encourages good design and rapid feedback and they seem to help teams avoid a lot of trouble.

  • It communicates across the network.
  • It touches the file system.
  • It can’t run correctly at the same time as any of your other unit tests.
  • You have to do special things to your environment (such as editing config files) to run it.

Test Driven Development (TDD)

TDD is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.

  • Second Law : You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
  • Third Law : You may not write more production code than is sufficient to pass the currently failing test.

Takes Care Of The Documentation

Documentation is a love letter that you write to your future self. — Damian Conway

Code Reviews Regularly

“Computer programming is an exact science in that all properties of the program and all consequences of executing it in any given environment can, in principle, be found out from the text of the program itself by purely deductive reasoning.” — Tony Hoare

Legacy Code

  1. Fixing a bug
  2. Improving the design
  3. Optimizing resource usage
  1. Break dependencies
  2. Write the tests
  3. Make your changes
  4. Refactor

Architectural Review

“An approach in evaluating software architecture is reasoning about the quality attributes a software architecture exhibits. Architecture review gives the general tone in these definitions is that you need to make high-level decisions about the system you’re going to build:

  • How is it going to function? How do structural components of the architecture work together?
  • How does it meet the needs of all the stakeholders?” — Software Architecture Review Guidelines by Alexander Nowak

Befriends Design Principles, Patterns and Architecture

Understanding the terms: design principles, design patterns and architecture can sometimes be confusing. Let’s look at it in simpler terms.

Pair Programming Time To Time

Pair programming is like a double-edge sword, done effectively, it does wonders, otherwise could be the cause of chaos. When practiced in the presence of an experienced technical leader, it can do magic - transform a novice into a reliable software engineer. Since most of the developers are so used to thinking alone and coding alone, and because of this predominant behavior pair programming is perceived difficult, which definitely is not as the team is not equipped well enough to do it properly. Therefore, it should be practiced time and again to boost the technical and personal growth.

Lives In The Cloud Native Landscape

Loves Live

Last but not least a successful software engineer love this profession! Loves life and finds a work-life balance.

Amor fati 🌱