Ask HN: What should be a software engineer's core competency?

As you said yourself a couple of days ago, there are many not a single one. I could answer "problem solving", "project management" or "time management" but that wouldn't fit the "area in tech" answer your employer is looking for.

"My new employer is telling me to develop a core competency (pick up an area in tech and become really good at it)" https://news.ycombinator.com/item?id=18038148

Engineering is about solving real world problems.

In order to be able to so you need to be able to communicate, as in "listen and ask good questions". Good engineering starts with accurately assessing requirements.

Design and design skills are vital, too. As an engineer you shouldn't just consider specific technical solutions but also take into account how those fit into the bigger picture and benefit the customer or - more generally - the user of the thing you're building.

Creating value. It sounds abstract but so far it's proven to be the most reliable and incontrovertible motivating ethos in my career. When you adopt a value-creation mindset, it washes into the calculus of just about every decision you make.

So, for example, if you're an early-stage company, a value-oriented mindset will lead you to the most efficient approach to get a working MVP. You might think about how you'll evolve the system, but you won't do something stupid like try to manage a complex Kubernetes deployment from the outset. You'll be careful not to introduce too many components into the system, understanding how even things that appear simple invariably affect the total risk profile of your system and, by extension, your business. You proceed in a manner such that the tech is responsive to and mirrors the business' requirements.

In data analysis, you won't go down stupid rabbit holes asking questions with answers that no one would care about. You'll prefer reliable, grokable statistical modeling on larger datasets to say using a deepnet to fit noise on a gratuitously tiny sample. You'll understand and accept that there are often questions you simply cannot accurately answer with the information available to you. You'll do the sometimes monotonous work of helping to instrument your business with metrics, because you understand that a business that can't quantify itself is effectively DoA (and therefore good instrumentation is among the highest value contributions you can make).

Honestly, I've discovered that the technical problems are nearly irrelevant. There's almost always a way. It's deterministic. What's so much more important is knowing how to identify the best use of your effort to drive value. The 10x engineer, in my mind, is someone who knows how to avoid blackhole projects and shitty decisions that eat up resources in exchange for a paltry or highly indeterminate return.

Note the above is largely relevant to resource-constrained businesses, which is most orgs other than maybe FAANG and similar.

I think the most upvoted answer will be problem solving, but instead I think it should be a broad liberal arts education, ethics, and learning how to say no. We've had enough of building machines as efficiently and ruthlessly as possible, it's time to start questioning the what and the why instead.

I have a friend who quite literally works on cluster bombs at Lockheed Martin and says they see no connection between their work and anything else in the real world. They just make "tools" like people at Facebook, it's not up to them how the tool is used.

We don't need any more software engineers like this who are good at solving problems and not much else.

This is far too generic, but here are some types of competencies-

>For Full Stack

Being a database expert, being a data expert, and API usages.

>For Embedded

Electrical Engineering(Primary) and Mechanical Engineering(as needed)

>For Automation

I'd simply recommend to prove yourself on Automation. When others are dazzled, you made it.

---

Any of these would be something that co-workers will be coming to ask you questions about.

Curiosity and Persistance

Learning quickly and understanding implications of cause and response.

IMHO This is a skill that should be a core skill in nearly all professions.

It's kinda up to you to decide, and what you decide will help dictate how your career evolves. It may be the case that your employer has some idea(s) in mind, in which case you should probably just ask - at least if you intend to stay there a long time. OTOH, if you accept that you'll likely move around throughout your career, and treat the whole thing as kinda fuzzy/probabilistic, then you have a lot of freedom to choose your core competencies... but recognize that you may evolve to the point where changing jobs (possibly even having to relocate geographically) may be necessary to keep on the path you choose.

All of that said, I can think of a few possible things to consider developing as core competencies:

1. Deep, deep knowledge of a specific language (Java, Go, Python, Rust, C++, COBOL, Agda, whatever)

1a. Deep knowledge of a lot of the associated tooling / ecosystem around your chosen language. For example, if you decided to become, say, a Java specialist, then the natural extension to that would be diving deep into an IDE like Eclipse or IntelliJ, a build tool like Maven or Gradle, popular libraries and tooling like JMS using ActiveMQ or HornetQ, the Servlet API stuff (if you want to build web apps), testing tools like JUnit, TestNG, EasyMock, etc., etc. If you chose Go as your language there would be a similar, but slightly different, list of "associated stuff" to consider. Note that Go or Rust might have a smaller "ecosystem" than, say, Java or Python, simply due to being younger. Further note that if you chose something a bit more esoteric (by modern standards) like, say, COBOL, then environment around that would likely be markedly different from that around more mainstream platforms like Java, Python, Javascript, etc.

2. Big Data -- you could choose to dive deep into Hadoop, Spark, Flink, Storm, and all of the trappings of the "Big Data" world.

3. HPC -- you could focus on C++, FORTRAN, etc., using MPI, OpenMP and the like, building Beowulf clusters, focusing on scientific computing, etc.

4. Machine Learning / AI

5. Embedded Systems -- firmware, device drivers, other low level programming. Maybe doing assembly language, or C/C++

6. Front end development - learn all about Javascript, HTML, CSS, React, Vue, etc.

7. Cloud -- learn all things cloud development --> all about one (or more) of AWS, GCE, Azure, Alicloud, etc.

Of course you could also look at all of those domains and try to pick out "what is common across all of these areas", and you'd probably wind up with something like "problem solving" as others have noted. And that is kinda core to everything. But it's arguably also just the price of entry, and something that should just be assumed for a competent software engineer.

Note to that there is always some overlap. Even if you are a "front end developer" there could well be times when you need to know some SQL or something. So you want depth and breadth of knowledge at the same time. Hence the idea of the "t-shaped"[1][2][3] person. Of course you can have more than one vertical bar, so you could be sorta "n shaped" or "m shaped" as well. Anyway, it's just a metaphor so don't get too caught up in it.

[1]: https://en.wikipedia.org/wiki/T-shaped_skills

[2]: http://coevolving.com/blogs/index.php/archive/t-shaped-profe...

[3]: https://stemfoundation.org.uk/asset/resource/%7B3EA5228A-B62...