Ask HN: How to become a software engineer as a self-taught front end developer?

[moonfleet]

I am a self-taught frontend developer with a couple years of experience. Though software engineering is a broad term that may cover some aspects of what I do professionally, I do not consider myself a software engineer. Maybe it's the lack of formal CS education or having minimal experience developing actual products as opposed to UIs for them.

Is being a software engineer a state of mind or an actual profession that comes with certain prerequisites?

[otras]

As many others have mentioned, the job title is largely arbitrary (at least in the US), and the easiest way to become a software engineer is probably to get hired for a job with that title!

As for whether or not you consider yourself to be a software engineer, that seems like a separate problem. I went through something similar when getting into tech, and I started as a self-taught front end developer before moving deeper into the stack at different jobs. I remember the feeling of there being a divide between the thin layer I worked with (JavaScript, CSS, React, etc) and much of how the rest of the software, the computer, and the internet work, and the divide felt very wide.

One thing that I've found helps with this is to build your foundational CS knowledge over time. I found CS classes (via CS50 and classes for a post-baccalaureate originally) beneficial for getting an introduction to concepts and areas that I was pretty unfamiliar with, and it has definitely helped to dissipate some of the fog around unknown concepts that I wasn't getting exposure to through my day job. I wouldn't say it was an over night shift, but the general knowledge has helped me become more confident about software in general, and that divide is barely there these days for me.

The only downside is that the classes expose you to the true depth of complexity in many areas (e.g. an intro compilers class vs. the real life complexity of gcc); it turns out you can go as deep as you want in so many different areas. It's a little unsettling to see the depth, but it's nice to go even a little deeper than the surface.

[jstx1]

The "engineer" part usually starts a discussion because in some countries it's a protected term so software engineers can't call themselves that. Or some people think that because the word engineer is in the title, people with the title should be held to some higher standard or somehow regulated - this isn't a thing anywhere for software engineers as far as I know.

> Is being a software engineer a state of mind or an actual profession that comes with certain prerequisites?

It's a job title. If your job has the title of software engineer, then you are one. The rest is either stories that you're telling yourself ("I do not consider myself a software engineer") or bullshit gatekeeping ("you're not a real $x until you do $y"). It doesn't make any difference whether your title is software engineer or software developer.

Titles aside, if you have a problem with confidence, spend more time learning and doing difficult things.

[zaphar]

If you can write javascript that solves problems you are a software engineer. Your skill level will vary in comparison to other people but there is no reason you can't call yourself a software engineer.

If you want continue to increase your skill level then the best way is to start branching out in the set of tools you can comfortably use. Write a small API server, Create some command line utilities for yourself, learn some different programming languages.

On each new think increase the difficulty level a bit. Push yourself, you'll continue to grow and your skill level will continue to vary in comparison to other because of it.

[rizzaxc]

To me being an "engineer" is when you have expertise in designing and building a "construct", that you have deep enough knowledge and experience to reason about the choices you and your team make when working on that construct, however large or small. Of course, this doesn't mean anything to anyone but me. So if you were to apply my definition to yourself, fill in the possible knowledge/ experience gap until you're always confident to explain your choices to an audience

[karmakaze]

I think of 'engineer'/'engineering' vs 'developer' in the software world as in the non-software world. There are inventors, hobbyists, researchers etc. But when it comes to coordinated projects with sizable team(s) or over a longer span of time, that's an engineering project.

So the best way to become a better software engineer (by this definition) is to work on projects with others (possibly opensource though that has additional aspects) or projects over longer periods of time. You find that your former self could well have been another developer, whose legacy you have to deal with. You learn to make things that age better, or designs that are easy to communicate and build upon.

I wouldn't preclude a front-end dev from being called a software engineer, but at the same time one that has experience in full-stack is much more aware of the tradeoffs that choices imply, to be a better one.

[drakonka]

Nuances of whether "engineer" is a protected title aside, I think feeling comfortable considering yourself an SE is less about whether you're doing frontend work and more about your confidence level and potential impostor syndrome.

It took me a while, too, to feel like I could honestly put "Software Engineer" in my LinkedIn profile. I'm self taught like you; went from build, to tools and engine, to backend, to frontend now. A few years in I just realized: that is what my literal title is in my contract and I am doing equivalent work of all the other formally and non-formally educated SEs on my team. So now, after over ten years of this, I feel no hesitation about calling myself a Software Engineer in relevant channels (although sometimes I just prefer the sound of "programmer").

[austincheney]

As a self taught front end developer in the US there are only two metrics that matters in software: employability and compensation. That means the ability to attain employment and make more money. That’s unfortunate because it does not directly speak to competence or problem solving potential. It’s also why many senior developers will intentionally shift away from trendy bullshit for less money.

As a self taught front end developer finding employment can be challenging. There appears to be a great divide in this line of work between candidate desirability and candidate competence. For example experience with a set of tools is more desirable than the ability to troubleshoot a problem and evaluation of either is highly biased.

[kidgorgeous]

Just keep applying for jobs in whatever specialty you want to get into. Can you code? Yes? That means you can solve problems. Titles are meaningless. And there's more job openings than people to fill them right now.

[beardyw]

There is no universal definition, nor could there be. But if I was using the term for a front end developer I would hope such a person would be comfortable with the concepts of anything I might pull up on MDN and have a reasonable understanding of HTTP, especially headers.

Mostly reading and a bit of experimenting at home.

[mosdl]

I always distinguish engineer vs developer in front end dev by asking if you understand how the frontend works (dom, js, css, etc) vs being able to build frontends using an existing framework.

For example, I once interviewed a FE person with 8 years of exp and he was convinced that only react vdom allows to update partial trees and that previously you had to rebuild and rerender the whole dom. He obviously did not understand how things work correctly.

[bionhoward]

Is being a software engineer a state of mind or an actual profession with certain requirements?

Why not both?

The only really hard prerequisites, for me, are

- Know how to write tests, and idiomatic code in the languages used by your desired shop

- learn how to read the manual, and how to write good docs

- learn to manage your emotions when stuff breaks or someone else disagrees. If you can simply stay calm even when the client is upset, stuff goes wrong, has bugs, or crashes, that's a tremendously valuable mindstate. Literal Stoicism.

- learn how to write, speak, and communicate.

- Be consistent with basic hygeine. Being gross is a silly way to limit oneself.

flow is the mindstate of all truly professional level hacking .. it requires you to master your field to a quasi-reflexive, instinctual level

curiosity is a fine motivator, and your "actual" products can be things which just satisfy your personal curiosity. It doesn't have to save the world or make money to be a side project worth putting in production (the cost is minimal to free these days)

For formal CS, Im a biologist but I definitely find working ridiculous numbers of algorithm challenges is the great equalizer. If you crush many algos then you will learn a ton. Goes for all of us, even pros and non technical people, there are challenges for all levels of skill, we all could get into the weeds more often and benefit IMHO

As for developing "actual" products, one nice way to make progress on that is to reach out to a few acquaintances and make sure they know you'd be down to help them hack out a project sometime. Some percentage would be interested and you could be a dev team of one. Also pair programming fun little web apps is good practice

It's good you're being humble but don't excessively discount the work you've already done -- you could add a backend and infrastructure as code to a front end you liked building and boom, you're in prod. Vercel makes this so easy it's not as much of an achievement as you think, but infrastructure as code has been known to make front end devs feel like they have superpowers.

Also, you could jump into the opposite side of the pool, like data science notebooks in Python or Julia. Machine learning is representation, evaluation, optimization (see "the master algorithm")

Most companies need great developers, you don't have to be a 10x developer to do a lot of good for somebody. In a lot of those companies you'll find it's useful to also master the domain you code for

Software engineering for me is like one of those neckbeard iceberg memes:

basic algos, SQL, backend, IaC, data science, ML, AI, arxiv, biorxiv, chemrxiv, medrxiv, quanta magazine, information theory (it clicked for me when I studied "information content"), algotrading, applied math, RL, learn the history of Bayes Theorem, transport theory is worth hacking on, definitely learn who are Leonid Levin and Ray Solomonoff, check out Judea Pearl, too, causality is still underutilized, also multiparty computation / secret sharing and crypto in general is really deep, then pretty soon it's 4AM and you're wondering how Schmidhuber invented the universe in the 1990s.

you can just explore randomly, and have fun, and eventually as long as you're not a criminal, you'll learn enough to have something to contribute. Yes, business and self help books count too.

Edit: just to pile on one more thought, one of the best skills a software engineer can possibly master, is that of diplomatically managing people's expectations about technology. For example we're the guys who have to convince our friends to consider the pros and cons of the latest and greatest fancy thing. Make sure to directly confront people who have unrealistic expectations and if you are a real engineer, then you provide real numbers, probability distributions over target measures with a margin of safety. Engineers also respect and learn standards like Oauth2 even if we don't like em