Valuable Concepts

3 minute read

Concept References
Ownership It is fundamental that Engineers feel that they own the product, but for this feeling to exist they need to constantly have access to the context. They need to keep informed about the personas, market needs, pain points (mainly the ones the products are trying to solve), and how the market operates. By doing this it will be natural to understand the strategy and roadmap as well as question them. Also, knowing all that helps have Empathy for the user.
Autonomy We can only move fast when we are not dealing with dependencies. Dependencies make us insecure (about deadlines, quality, and scope) and create impediments/barriers all the time on the way.
Accountability Accountability is being responsible for the things you build as well as taking care of it once it is live. Accountability is not a way to point fingers, but a way to have someone or a team that is responsible for a fraction of is being built. If some error occurs the team has sense of accountability to acknowledge it and work on a fix. Accountability is almost impossible to overcome.
You build it,
You ship if,
You fix it


This combines some of the concepts above.
  • To enable autonomy you must have Ownership over the context as well as technically (architecture, code, workflow).
  • To be able to build and ship (put in production), it is required Autonomy.
  • “fix it” means you are accountable and, to be accountable, you need Autonomy to build it and ship it
    		•
    KISS
    		(Keep It Simple, Stupid!)
    That just may be the engineer’s ultimate motto. Engineers tend to build complex systems which cause problems when it comes to their debugging and maintenance. That is why simplicity is the way to go! Whether it is applied to your code or your problem-solving process, keep in mind that keeping it simple is not as easy as it sounds, but it can prove much more effective than complicated structures.
    DRY
    		(Don’t Repeat Yourself)
    An effective code can be highly reusable and that is a good thing, but it doesn’t mean that this piece of code should be repeated in various places within a program. Instead of repeating yourself and your code, see if there is a way to combine all snippets (create libraries or APIs), thus minimizing the time of effort you will spend if it is necessary to make any improvement or fixing in the future.
    YAGNI
    		(You Aren’t Gonna Need It)
    A frequent temptation for developers is the urge to take any future eventuality into account and proceed to write code that will solve it. However, hands-on experience has proven that this proactive way of working is a waste of effort. So, focus on building the code that you need at the moment!
    S.O.L.I.D.




    		S.O.L.I.D. is an acronym that contains five design principles in object-oriented computer programming
  • Single Responsibility Principle: every module or class should have only a single responsibility (i.e. only changes to one part of the software’s specification should be able to affect the specification of the class).
  • Open/Closed Principle: software entities should be open for extension but closed for modification.
  • Liskov Substitution Principle: objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
  • Interface Segregation Principle: many client-specific interfaces are better than one general-purpose interface.
  • Dependency Inversion Principle: one should depend upon abstractions, [not] concretions.
    		•

    References

    		 The Manager’s Path - by Camille Frontier
    A Guide for Tech Leaders Navigating Growth and Change
    Key takeaways
  • “One-on-one meetings with your manager are an essential feature of a good working relationship.”
  • “A manager’s job involves making it easy for her employees to get things done by creating fertile environments in which work can happen.”
  • “Mentoring new hires is critical.”
  • “Feedback works best when you, as a manager, pair that feedback with coaching.”
  • “It’s unrealistic to think you can or should shield your team from everything.”
    		•
    		Production-Ready Microservices - by Susan Fowler
    Building Standardized Systems Across an Engineering Organization
    		Microservices Patterns - by Chris Richardson
    		Refactoring - by Martin Fowler
    Improving the Design of Existing Code