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


