The “Software Engineer” Mindset

What is a software engineer? And what is a senior software engineer? Many companies define a “senior software engineer” as a person who has spent more then 6 years as a programmer. And that’s not always correct.

The other day I was asked whether I recommend becoming a “generalist” or a “specialist”. Whether one should stay focused on one particular technology and become really proficient with it, or do a little bit of everything. I once wrote that if you do a little bit of everything, you become no expert at all. And while I still partially hold that view, it needs to be elaborated.

The software engineer mindset never results in narrow specialists. But it doesn’t mean you don’t “drill” into a particular technology. In fact, you drill into many particular technologies/frameworks/levels of abstractions. You become proficient with them, then you move on to the next one. Probably with side projects, probably as transitioning from one job to another, where something unfamiliar is used alongside the known bits. Over time, you gather enough experience that each new technology is familiar and you get into it pretty quickly. On the other hand, staying focused on one particular technology for a long time doesn’t let you see the full spectrum of possible solutions to a problem. So no, doing mostly jQuery/Rails/Spring/Android/… for 15 years doesn’t make you a “senior software engineer”.

The software engineer mindset is about solving the problem. The more senior you are, the faster you are in finding simpler solutions. The more technologies you are familiar with, the more non-localized solutions you are able to produce – in a multi-technology project (web, android and iOS frontends, with a java backend, a public API, for example) a solution that looks okay in one particular technology, may be a hack in the rest.

The software engineer mindset is not saying “I don’t know about that, another colleague was doing it”. I’ve been getting answers like this on interviews – people have even been implementing JSR specs, and only knew the part they were working on for the past 2 years. How it fits with the rest is what the software engineer should be concerned with.

Isn’t that the role of the architect, some people may ask. But the architect is a role, not a job. Each software engineer with the right mindset and knowledge is an architect, and should be. Maybe one will represent the team in front of committees (if such are needed at all), but the top-down architect approach is broken. Mostly because an architect-only position doesn’t get to write code, and loses grip with reality soon enough.

Maybe I’m trying to label what I like doing (going into all parts of the application, from the high-level architecture to the low-level details) as a “software engineering mindset”. And maybe I’m just adding yet another synonym for the “full-stack developer” cliche. Anyway, I think it’s good to encourage people to see the broader technology landscape, and it is equally important to encourage them to spend time focusing on particular problems and technologies. Otherwise they may become one of those architects and seniors, that pretend to know a lot, but haven’t actually seen the intricate details. And the devil is in the detail. The software engineer has both.

5 thoughts on “The “Software Engineer” Mindset”

  1. Interesting. I remember what Dan North once said.

    “Our job is not programming. Our job is not software. About 30 years ago we did ourselves a massive disservice, by calling what we do “Software Engineering”. It’s a lot like plumbers calling what they do “Pipe pending”, but they don’t do pipes, they provide heating!

    We are not in the software business, we are in the information business.

    The asset here is business capability. Our job is to provide business capability.

    Software (our code) is the liability (cost) we incur to realise that business capability. The most effective programmers are some of the least productive. They figure out what software they need, they write only that software and it has enormous business impact.”

  2. I would add to the scope of a “software engineer”, assist in requirements engineering as that’s where it all starts (even if it’s a ‘side project’ (POC) as a means of investigation).

    My view is that a ‘software engineer’ is a problem solver, in its true essence. I found that, at times, the solution to a particular problem is non-technical (could be process, workflow, etc.).

    I’m old school and entered the field when there was barely any Internet (as we know it today), the search engines where Veronica, Archie and JugHead where you had to read the manuals for the most part; you had to be knowledgeable, not necessarily expert, in various aspect of the craft: database, network, etc. which makes for a well-rounded perspective.

    I agree with most of what has been said but I think what is left out is ‘sharing the love’ and developing talent.

    Good stuff! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *