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.
| Reference: | The “Software Engineer” Mindset from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog. |
