by moonfleet on 11/17/21, 10:52 AM with 11 comments
Is being a software engineer a state of mind or an actual profession that comes with certain prerequisites?
by otras on 11/17/21, 3:09 PM
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.
by jstx1 on 11/17/21, 11:14 AM
> 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.
by zaphar on 11/17/21, 1:10 PM
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.
by rizzaxc on 11/17/21, 12:25 PM
by karmakaze on 11/17/21, 3:25 PM
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.
by drakonka on 11/17/21, 12:09 PM
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").
by austincheney on 11/18/21, 9:20 AM
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.
by kidgorgeous on 11/17/21, 10:58 AM
by beardyw on 11/17/21, 12:40 PM
Mostly reading and a bit of experimenting at home.
by mosdl on 11/17/21, 4:53 PM
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.
by bionhoward on 11/17/21, 4:06 PM
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