DEV Community

loading...
Cover image for Work as Developer, Think like an Engineer: Vertical + Horizontal Knowledge

Work as Developer, Think like an Engineer: Vertical + Horizontal Knowledge

manuelbarzi profile image manuelbarzi Updated on ・3 min read

I see a lot of devs in love with React, Redux, Node, … and so on. Ok, that's cool but how far does that take you? It’s pure technology.

What about software engineering, architecture, principles, design patterns, best practices, testing, etc?

Here's where cross-knowledge or vertical and horizontal knowledge come into play.

Let's keep knowledge as a broad concept that involves learning and experience.

Regarding vertical... for instance, you can know more or less of different technologies, you can be an expert in React and Redux, and you can also be a beginner in HTML, CSS and Sass. The greater or lesser amount of knowledge you have in these specific subjects is what defines your vertical knowledge.

So vertical means the depth of your knowledge in a particular thing. The more knowledge you have in the subject, the greater your vertical in that specific area.

Now what about horizontal?

The process of learning and gaining knowledge that is applicable across various domains, scenarios, and technologies is what we would call “horizontal knowledge”.

I am not referring here to specific technologies or languages, such as JavaScript, being applied both on the client and server side, for instance. This is not horizontal knowledge, but rather vertical knowledge: the fact that it is being applied in different areas of the stack doesn't mean you’re increasing your horizontal knowledge.

Horizontal knowledge means PURE Software Engineering, it means depth in Design and Architecture.

When you combine both vertical and horizontal knowledge, that's what makes "The Plus".

Cross-Knowledge

So, if at the moment you find yourself in love with various technologies — React, Redux, TypeScript, etc — it is time to also start taking on board software engineering principles, such as Design Patterns, Best Practices, etc and adding these horizontal elements to your coding practice. This will improve your "cat's eyes" (|)(|) into "lion's eyes" (+)(+).

If you do this, you will see further, and you will also gain intuition: you will detect "patterns", you will gain more ways of thinking that you can apply in more than one scenario. You will be able to continue to develop code, but do it with more care, in a different, “wider”, way. Your code will follow a different mindset, a higher projection.

For me, I see this as the difference between "coding just for yourself" vs. "coding for me, my colleagues and my company". When you work for a company, your code is part of a collective thing, the company, a project, and that's not something to be taken lightly. It involves a lot of responsibility.

Thus, when you code both horizontally as well as vertically — taking into account not only the latest and greatest technologies, but also fundamental software engineering principles — not only do you gain, but the company you work for gains as well: maintainability, reusability, efficiency, scalability — as well as the ability to take a “big picture” approach to your development — all add value to your code.

When you work on CSS, for instance, applying composition through Sass and BEM, you can use that knowledge of composition when composing with React. Or when you are engineering the business logic on a client and server architecture for an SPA consuming an API, you can notice that both sides require analogous Separation of Concerns, projection through layers, testing... etc, etc, etc.

Everybody gains: you, your mates, and the company.

So, this is it. Do not settle for being simply a master in technologies, push yourself to go further, learn Software Engineering, Design and Architecture, and add both the vertical and horizontal knowledge to your daily practice. All in all it's also a question of improving, a question of attitude. Be a plus: work as a Developer, think like an Engineer. Be a PRO dev!

UPDATES

  • 20181124: spelling and expression corrections
  • 20181127: text improvements (thank you, Robert Anthony! ,)

Discussion (5)

pic
Editor guide
Collapse
vgamezz19 profile image
Víctor Gámez

Nice post!! I really want to be a Leon :3.

An other way, if you are reading this, and you want to start study software stuffs, I recommends you follow this amazing Study Path!! It's powerful.

github.com/joebew42/study-path

Collapse
ddmarin94 profile image
David Marín

Great post mate! 👏

Collapse
qm3ster profile image
Mihail Malo

Imagine calling it "PLUS" instead of "HORVER"

Collapse
danielsreichenbach profile image
Daniel S. Reichenbach

TL;DR: it is not about the Tools, it is about understanding what is behind all things. Looking behind the curtains is what makes a great engineer!

Collapse
manuelbarzi profile image
manuelbarzi Author • Edited

Both things are important. Tools (tech) are what usually "hooks the fish", and then the question arises: "how does this work?". In other words, it is not only the WHAT, but also the HOW; both things are important.

As a DEV you may have specialised, focussing on certain techs more than others, that's why you are also "a DEV", and probably a good one on those techs, working for one or more companies (vertical knowledge).

But then you may improve getting deeper, "understanding how things work", the patterns and principles behind, the design and the architecture at the end, and then getting closer to an Engineer mind (horizontal knowledge).

It's not about just focussing on "a pure engineer", but on "a developer approaching to an engineer", making engineering an inclusive thing into development, not just exclusively engineering, nor exclusively development.