Core Values Of A Software Engineer

Every so often I find myself returning to the fundamentals. Nevertheless, sometimes it feels like retracing old steps. But each iteration provides new insights and perspectives when introspective carefully.

A journey of repetitive learning and novel revelations is the bedrock of experience. With managed experiences, observed, analyzed and planned, an expertise is gained - an ability to see and make connections previously unseen which is achieved by continually evolving and adhering to core values of software engineering.

The core values of a software engineers are:

• Quality attributes
• Computer science
• Design principles, patterns and architecture
• Documentation
• Clean code
• Test driven development
• Maintenance
• The Cloud Native Landscape
• Life balance

Software Quality Attributes

In the ever-evolving landscape of software development, understanding and prioritizing software quality attributes is non-negotiable. As developers, it's our responsibility to not only write functional code but also ensure that the software meets the highest quality standards. By embracing domain knowledge, leveraging quality models, and continuously upskilling, we set ourselves, our teams, and our products up for success.

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

Software quality attributes, often referred to as non-functional requirements, define how a system is supposed to be rather than what it's supposed to do. These attributes include performance, security, usability, maintainability, and scalability, among others.

Why is it Important?

Understanding these attributes aids in making informed decisions during the software development lifecycle. It enables developers to prioritize certain attributes over others based on the application's needs and potential trade-offs.

- How to Achieve It?

- Training & Workshops: Regular training sessions can introduce and drill in the importance of these attributes.

- Tools & Automation: Leveraging tools that assess code quality, security vulnerabilities, and other attributes can automate some aspects of quality assurance.

- Feedback Loops: Regular feedback from stakeholders, including users, can provide insights into which quality attributes are most crucial.

The Role of Quality Models in Software Development

Quality models, like the ISO/IEC 25010, provide a structured approach to understanding and measuring software quality.

- Why Use Them?

They offer a standardized way to define, measure, and evaluate software quality, ensuring that all stakeholders have a common understanding.

- How to Implement Them?

- Team Workshops: Regular workshops can be organized to familiarize the team with the chosen quality model.

- Integration into SDLC: Integrate the quality model checks at various stages of the software development lifecycle.

- Regular Audits: Periodic audits can ensure compliance with the quality model.

Document Domain Knowledge

The key to building software product with quality is solidifying domain knowledge and documenting the requirements.

Every product has its unique set of requirements. An e-commerce application might prioritize performance and security, while a content management system might focus more on usability and maintainability.

- Why is it Important?

Deep domain knowledge equips developers with the context needed to make the right decisions regarding quality attributes.

- How to Acquire It?

- Stakeholder Interviews: Engaging with clients, end-users, and other stakeholders can provide valuable insights.

- Market Research: Understanding competitors and market standards can set a benchmark for quality.

- Continuous Learning: As markets evolve, so do the requirements. Staying updated with industry trends is crucial.

Computer Science

Software engineering isn't solely about producing code. It revolves around the core tenets of computer science: hardware understanding, efficient algorithms, and the proper use of data structures.

These foundational elements guide us in designing systems that are robust, efficient, and scalable.

Diving deep into computer science basics empowers engineers to construct efficient, scalable, and reliable software. It's not just about writing the code, but understanding the underlying principles, making informed decisions, and realizing the trade-offs involved. As you tread the software development path, fortify your foundations, and let them guide you to excellence. And remember, mastery in these domains doesn't just make one a better programmer, but also a pivotal contributor to the team's vision and success.

1. Hardware

While it's not imperative for an application developer to delve deeply into the intricacies of hardware as an embedded systems developer might, a basic grasp is indispensable. Recognizing the distinctions between types of computer memory (like RAM and ROM) and storage devices (HDD vs. SSD) offers insights when designing software solutions. With the rise of parallel processing in multi-core CPUs, even a cursory understanding of how a CPU operates becomes essential.

Why? The efficiency of software operations is often contingent upon hardware specifications.

How? Regular workshops, webinars, or short courses can help developers attain this knowledge.

2. Data Structures

“Algorithms + Data Structures = Programs.” — Niklaus Wirth

Data structures are pivotal in organizing and storing data in a manner that facilitates efficient operations. They act as the blueprint for Abstract Data Types.

Different data structures cater to varied applications, and their judicious selection can profoundly impact software performance.

Why? Data structures directly influence software efficiency, scalability, and maintainability.

How? Regular training sessions, both in-house and external, can foster a better understanding of data structures.

Selecting the Ideal Data Structure

Choice of data structure is guided by several considerations:

• Does the application demand random access?
• Are frequent insertions and deletions expected?
• Is the ordering of data pivotal?
• Is traversal of elements necessary?
• What's the anticipated data volume?

3. Algorithms

While an algorithm is essentially a set of rules to solve a problem, its creation isn't a straightforward transposition of pseudocode to code. It demands a nuanced understanding of the problem, coupled with adeptness in data structures.

A grasp of problem categories like P and NP can guide in determining optimal solutions.

Why? Efficient algorithms are the bedrock of speedy software operations, directly affecting user experience.

How? Regular team brainstorming sessions, workshops, and engaging with algorithmic challenges can hone these skills.

Recognizing Problem Complexities: P vs. NP

P (Polynomial) Problems: These are problems where solution algorithms execute in polynomial time. Basic mathematical operations, certain search algorithms, and path-finding algorithms are typical examples.

NP (Non-deterministic Polynomial) Problems: Solutions to these problems don't necessarily run in polynomial time but verifying a provided solution does. Examples include the Traveling Salesman and Knapsack problems.

Recommended Readings

• "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma et al. - for understanding design patterns.
• "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin - offers insights into writing readable, maintainable code.
• "Computer Networking: A Top-Down Approach" by James F. Kurose and Keith W. Ross - an excellent resource for understanding networking.
• "Effective Communication for Colleges" by Brantley Clarisse - delves into enhancing communication skills, essential for both leadership roles and team collaborations.

"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

Design Principles, Patterns And Architecture

Understanding the design principles, design patterns and architecture, and their differences is critical for software engineers growth, to be able to make the higher value trade-offs on a daily basis towards desired system capability as per business need.

Furthermore, these are the technical tools to dive deeper into systems thinking.

Let's look at it in simpler terms.

Design Principle

Design principles provide high level guidelines to design better software applications and they do not provide any implementation and are not bound to any programming language.

Some widely used principles are:

Do One Thing And Do It Well - Unix Philosophy

Keep It Simple Stupid (KISS)

Don’t Repeat Yourself (DRY)

You Aren’t Gonna Need It (YAGNI)

SOLID (Single Responsibility, Open-Closed, Liskov-Substition, Interface Segregation)

Design Pattern

Design patterns provide low level solution implementation (components of a subsystem with their relationships and collaborations with each other) for the commonly occurring problems and suggest specific implementation for the specific object oriented programming problem.

Design patterns may be viewed as a structured approach to programming that acts as an intermediate between the levels of a programming paradigm and a concrete algorithm. For example: Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

The book "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides defines three types of design patterns: creational, structural and behavioral.

The book “Object-Oriented Analysis and Design with Applications” by Grady Booch can be of good help to relate and differentiate core ideas more with simple explanations and examples. His principles, The Principles of Hierarchy, Abstraction, Modularization, and Encapsulation(PHAME) abstracts the overall understanding.

Software Architecture

Architecture is concerned with further higher level like the subsystems of an application with their relationships and collaborations with each other, the relation of one application to another and the entire solutions.

An architect chooses the desired quality attributes by understanding their trade-offs. Everyone has their own definition of an architect, and this is mine.

“Architecture is selling options.”- Gregor Hophe

Primarily there are three levels of architectures created by Technical Architect (Software Architect, System Architect), Solution Architect and Enterprise Architect.?Let's understand them in brief.

Technical architects are higher technology focused and a lower strategy focused so they have a more hands-on approach defining best practice standards to follow, for example, Java Architect, Infrastructure Architect, Security Architect.?

Solution architects typically straddle the middle position when it comes to strategy versus technology focus and organizational versus project scope. A Solution architect is responsible for designing a high level solution to a specific set of business requirements, within the framework laid down by the enterprise architecture team. This solution may span multiple applications.?

Enterprise architects are responsible for strategic thinking, roadmaps, principles, and governance of the entire enterprise. They usually have a close relationship with the business, vendors, and senior IT management and therefore, handle the entire enterprise with the main interest in describing the company in terms of its business entities, its properties and the relations between them and the external environment. One of the principal concerns of Enterprise architecture are the lifecycle of the applications and what technologies are used by which one. At the same time, they ensure that the company as a whole has integrity and consistency.

Documentation

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

“Working software over comprehensive documentation” is one of the Agile Manifesto’s four value statements but well maintained documentation can be a great catalyst for some of the other agile principles, like “Simplicity”, “Business people and developers work together daily”, “Attention to technical excellence and good design”, or “The team regularly reflects on how to become more effective”.

The right level of documentation are invaluable artifacts. They help increase the life-expectancy by giving the correct level of quality information of the system and stops software corrosion and slowing the process for it to become the legacy. The challenge is in defining what are the correct ways to document for that we can ask some questions like:

How much documentation is necessary?

When do we do it?

What are the types of documentation?

How to maintain it?

What tools are available?

Various types of documentation must be done for all of the communication depending upon the the nature of the work. For example, for architectural design visual documentation are easier, for comments are preferred for code, or important meeting minutes.

Code changes are much easier to rationalize but architectural decisions are hard because architectural changes are not necessarily reflected in code. To stress this point, in his 2011 blog post about architecture decision records, Michael Nygard writes: “One of the hardest things to track during the life of a project is the motivation behind certain decisions.” But, he adds, unless you understand that rationale, you can only either accept the decision blindly or reject it blindly. Writing down the reasoning, context, and consequences of a decision right after you take it can hugely improve future decision-making.

“Your most important architecture decisions might be the ones you didn't know you made. Conscious decision making is a major step towards better architecture. Unconscious decisions often come in the form of assumptions. Assumptions are risky because they lead to non-requirements, those requirements that exist but weren’t documented anywhere. Tacit assumptions and unconscious decisions both lead to missed expectations or surprises down the road.” — Gregor Hohpe (The Architect Elevator)

To document architecture, UML has been used predominantly for system and architectural documentation tool.

With the need to document non-functional choices, Architectural Decision(AD) emerged in the last decade. AD addresses the non-functional choices made that is architecturally significant.

An Architecturally Significant Requirement(ASR) is a requirement that has a measurable effect on a software system’s architecture and quality.

An Architectural Decision Record (ADR) captures a single AD, such as often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM). Source

Complicate and the larger scale of the system needs more comprehensive up to date documentation.

It is better to tracked it along with the code changes in the version control system. Before any merge, like code is reviewed, documentation must also be reviewed. Therefore, it is recommended to keep the code and its necessary documentations are tracked in the same repository.?

Strict documentation and its management is much more important in open

source projects as without it would be extremely hard for contributors to collaborate.?

“Code is more often read than written.” — Guido van Rossum

“Code tells you how; Comments tell you why.”— Jeff Atwood

Clean Code

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

“Code is more often read than written” — Guido van Rossum

I cannot emphasize more about the value of writing human readable code than the text excerpt from the book “Clean Code” — Robert C. Martin.

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well. — Bjarne Stroustrup

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control. — Grady Booch.

Code Sense

"As the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero. As productivity decreases, management does the only thing they can, they add more staff to the project in hopes of increasing productivity.

But that new staff is not versed in the design of the system. They don’t know the difference between a change that matches the design intent and a change that thwarts the design intent.

Furthermore, they, and everyone else on the team, are under horrendous pressure to increase productivity. So they all make more and more messes, driving the productivity ever further toward zero.

A programmer without code-sense` can look at a messy module and recognize the mess but will have no idea what to do about it. A programmer with `code-sense will look at a messy module and see options and variations.

The code-sense` helps programmers choose the best variation and guide him or her to plot a sequence of behavior preserving transformations to get from here to there."

— Grady Booch

At the heart of clean code is well written function.

Function

Functions are the building blocks of any software 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!

General guideline to write quality functions:

• A function should be small, 8-10 lines max.
• 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.

Code is a standard that can be understood easily by everyone in the team. It should make the code readable and changes easier by other than its original author. With such understandability comes readability, changeability, extensibility and maintainability.

Clean Code Framework

Some rules to implement clean code from the book 'Clean Code' by Robert C. Martin.

General Rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design Rules

1. Keep configurable data at high levels.
2. Prefer polymorphism to if/else or switch/case.
3. Separate multi-threading code.
4. Prevent over-configurability.
5. Use dependency injection.
6. Follow Law of Demeter. A class should know only its direct dependencies.

Understandability Tips

1. Be consistent. If you do something a certain way, do all similar things in the same way.
2. Use explanatory variables.
3. Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
4. Prefer dedicated value objects to primitive type.
5. Avoid logical dependency. Don't write methods which works correctly depending on something else in the same class.
6. Avoid negative conditionals.

Names Rules

1. Choose descriptive and unambiguous names.
2. Make meaningful distinction.
3. Use pronounceable names.
4. Use searchable names.
5. Replace magic numbers with named constants.
6. Avoid encodings. Don't append prefixes or type information.

Functions Rules

1. Small.
2. Do one thing.
3. Use descriptive names.
4. Prefer fewer arguments.
5. Have no side effects.
6. Don't use flag arguments. Split method into several independent methods that can be called from the client without the flag.

Comments Rules

1. Always try to explain yourself in code.
2. Don't be redundant.
3. Don't add obvious noise.
4. Don't use closing brace comments.
5. Don't comment out code. Just remove.
6. Use as explanation of intent.
7. Use as clarification of code.
8. Use as warning of consequences.

Source Code Structure

1. Separate concepts vertically.
2. Related code should appear vertically dense.
3. Declare variables close to their usage.
4. Dependent functions should be close.
5. Similar functions should be close.
6. Place functions in the downward direction.
7. Keep lines short.
8. Don't use horizontal alignment.
9. Use white space to associate related things and disassociate weakly related.
10. Don't break indentation.

Objects And Data Structures

1. Hide internal structure.
2. Prefer data structures.
3. Avoid hybrids structures (half object and half data).
4. Should be small.
5. Do one thing.
6. Small number of instance variables.
7. Base class should know nothing about their derivatives.
8. Better to have many functions than to pass some code into a function to select a behavior.
9. Prefer non-static methods to static methods.

Tests

1. One assert per test.
2. Readable.
3. Fast.
4. Independent.
5. Repeatable.

Code Smell

1. Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
2. Fragility. The software breaks in many places due to a single change.
3. Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.
4. Needless Complexity.
5. Needless Repetition.
6. Opacity. The code is hard to understand.

Test Driven Development

“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?

Test Driven Development is a programming philosophy that helps improve the quality of code by helping the developers improve their critical thinking process through writing tests first.

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.

The Three Laws of TDD:

• First Law : You may not write production code until you have written a failing unit test.
• 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.

The extension of TDD is Behavior Driven Development(BDD) in agile methodologies that represents User Stories and gives TDD a specific format of “Given, When, Then”. In order to improve TDD skills “Red-Green Refactor“ method coined by James Shore can be very much useful.?

Writing better functions and unit tests enables programmers to implement TDD.

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.

A test is NOT a unit test if:

• It talks to the database.
• 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.

Maintenance

We must design and develop our system to be maintainable. We do it by writing clean code and adhering to the best engineering practices. But many times we work legacy systems and working with such system is a challenge.

For system old and new, regular maintenance is must. Reviewing and refactoring the architecture and code is a part of maintenance.

Reviews facilitate knowledge interchange to increase software quality. They are an opportunity for others to look at our documents, design, code, software architecture and for you to inspect others' work. They help us to spot faults before they become real disasters. As important it is to review, it is also important to do it the right way. So standard processes must be followed and results must be measured..

“What do you think about when you hear the term legacy code? If you are at all like me, you think of tangled, unintelligible structure, code that you have to change but don’t really understand. You think of sleepless nights trying to add in features that should be easy to add, and you think of demoralization, the sense that everyone on the team is so sick of a code base that it seems beyond care, the sort of code that you just wish would die. Part of you feels bad for even thinking about making it better. It seems unworthy of your efforts. That de?nition of legacy code has nothing to do with who wrote it.

Code can degrade in many ways, and many of them have nothing to do with whether the code came from another team.

In the industry, legacy code is often used as a slang term for dif?cult-to-change code that we don’t understand. But over years of working with teams, helping them get past serious code problems, I’ve arrived at a different de?nition. To me, legacy code is simply code without tests.?

Four primary reasons to change software.

1. Adding a feature
2. Fixing a bug
3. Improving the design
4. Optimizing resource usage

Behavior is the most important thing about software. It is what users depend on. Users like it when we add behavior (provided it is what they really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us." — Michael C. Feathers, Working Effectively with Legacy Code

Requirements change. Designs that cannot tolerate changing requirements are poor designs to begin with. It is the goal of every competent software developer to create designs that tolerate change. This seems to be an intractably hard problem to solve. So hard, in fact, that nearly every system ever produced suffers from slow, debilitating rot. The rot is so pervasive that we’ve come up with a special name for rotten programs. We call them: Legacy Code. — Robert C. Martin

Preserving existing behavior is one of the largest challenges in software development. Even when we are changing primary features, we often have very large areas of behavior that we have to preserve. To mitigate risk, we have to ask three questions:

1. What changes do we have to make?

2. How will we know that we’ve done them correctly?

3. How will we know that we haven’t broken anything?

How much change can you afford if changes are risky? Some teams mandate “If it’s not broken, don’t ?x it”.

We can follow these steps while refactoring legacy code:

1. Identify change points (Seams)
2. Break dependencies
3. Write the tests
4. Make your changes

An important part of code review is refactoring. I have seen refactoring being so much opinionated that everyone has their own version while doing it. To standardize the refactoring I recommend “Refactoring Improving the Design of Existing Code” by Martin Fowler.

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.

• What style are you going to use? What is the structure?
• 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????

Code Review

“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

The code reviewing process should also be automated. Static and Dynamic Analysis Tools should be used to automate maintaining the quality of code whereas Unit and Functional tests should should be used to catch any breaking updates. Both of these task can be automated via Git-hooks giving more time for the team to focus on other matters such as self-improvement.

Pair Programming

Pair programming is like a double-edge sword. When done effectively, it does wonders, otherwise could be a cause of chaos. But in the presence of a good technical leader, it can do magic, transform a novice into a reliable software engineer.

Most of the programmers are so used to thinking alone and coding alone. pair programming is perceived difficult because of this predominant behavior.

Hence, in order to bring the values of collective design thinking, pair programming must be practiced that boosts individual growth and team mentality.

The Cloud Native Landscape

A successful software engineer understands the Cloud Native landscape. The Twelve-Factors App is the manuscript that helps to build in the Cloud. In short, it is a methodology that every successful engineer follows while building cloud-native distributed applications.

The sweet version of the manuscript:

Code: Manage all code in version control systems (like Git or Mercurial). The code base comprehensively dictates what is deployed.

Dependencies: Dependencies should be managed entirely and explicitly by the code base, either vendor specific (stored with the code) or version pinned in a format that a package manager can install from.

Config: Separate configuration parameters from the application and define them in the deployment environment instead of baking them into the application itself.

Backing Services: Local and remote services are both abstracted as network-accessible resources with connection details set in configuration.

Build, Release, Run: The build stage of your application should be completely separate from your application release and operations processes. The build stage creates a deployment artifact from source code, the release stage combines the artifact and configuration, and the run stage executes the release.

Processes: Applications are implemented as processes that should not rely on storing state locally. State should be offloaded to a backing service as described in the fourth factor.

Port binding: Applications should natively bind to a port and listen for connections. Routing and request forwarding should be handled externally.

Concurrency: Applications should rely on scaling through the process model. Running multiple copies of an application concurrently, potentially across multiple servers, allows scaling without adjusting application code.

Disposable: Processes should be able to start quickly and stop gracefully without serious side effects.

Dev/Prod: Your testing, staging, and production environments should match closely and be kept in sync. Differences between environments are opportunities for incompatibilities and untested configurations to appear.

Logs: Applications should stream logs to standard output so external services can decide how to best handle them.

Admin Processes: One-off administration processes should be run against specific releases and shipped with the main process code.

Agility

To be agile, we must understand that it only works by first admitting that the old “waterfall” method of software development leaves a lot to be desired.

The conveyor belt process of “plan, design, build, test, deliver,” works okay for making cars or buildings but not as well for creating software systems where knowledge work is at the root and the plan is necessarily never complete because the requirements can not be completely specified due too many unknown variables.

Nevertheless, agility needs some rules to follow, and thus, requires significantly greater discipline in order to function in a more dynamic environment. Therefore, Software engineers must embrace agile as a discipline that nurtures adaptability and resilience to adapt to the rapidly changing world. And agile methodologies are the framework for creating the necessary discipline.

Scrum and eXtreme Programming are agile methodologies tools which are people-focused. They should be flexible, fast, and aim for continuous improvements being centered around adaptive planning, self-organization, and short delivery times.

The Agile Manifesto are the principles that guides the agile frameworks.

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

Life Balance ??

To excel as an engineer, we must love ourselves, and find a balance in how we live. We must take care of our mental and physical health, so that we can take care of others around us. We must also love what we do and do it well enough. We must try to understand ourselves, our strengths and realize other aspects where improvement is necessary and we can only do that by being a continuous self-learner.