My dad started teaching me Basic when I was about 7 years old, and since about that age I knew that I wanted to build software for a living. It was obviously a fun and useful thing to do, and something that I could do well. But there is a big — and I mean Grand Canyon-scale BIG — difference between “programming” and working as a professional software engineer.
Here are, in no particular order, some things that nobody told me about working in tech as a software engineer:
- That it is normal to have more lines of tests than production code.
- That having no choice but to use
viearly in my career would mean that I can never leave those keybindings behind. - That we spend a ridiculous amount of time setting up builds, releases and general tooling. Sometimes as much or more time that you spend coding. (And don’t even get me started about operations, on-call and all the other pieces that turn “programming” into “a product in hands of users”.)
- That my gender or my age or my ethnicity or my sexual orientation or my weight or my clothes might (will!) have an impact on the perceived quality of the software I build. (Or, in other words, that this is not really a meritocracy, and doing a good job is not nearly enough.)
- That writing code is only a small part of what goes into shipping production software.
- That so much of my work life would be subordinate to the choices of barely-clued-in VCs, and overwhelmed first-time founders with no industry experience.
- That everything old is continuously made new again — from MySpace to Facebook, from IRC to Slack. PHP is cool again, and functional programming is trending.
- That having decent people skills makes my technical skills suspect, in the eyes of some.
- That learning to manage my own energy and mindset is the most important skill through gnarly debugging and hairy code reviews alike.
- That you can have more than a 100% base salary difference doing the same job, depending on if you work at a small startup or one of the large companies.
- That not all software engineering roles have the same cachet in the eyes of the local culture. (Alternatively: that good frontend and test automation specialists are grossly undervalued.)
- That the idea that working at a small startup will make you rich is outdated. Barely anyone IPOs these days, and you can save up more easily if you work for a bigger, stable company.
- That CSS is the most complex modern programming language.
- That internships should always be paid at market rate.
- That spunky online book vendor would become synonymous with distributed infrastructure. That the new Altavista competitor would become a less bad Microsoft Office. That the new version of My Space would help damage democracies the world over.
- That, 15-ish years in, my main professional contributions could be summarized as: nudging folks to write better and/or more tests, and getting people to talk to each other.
- That the best technology doesn’t necessarily win. In fact, it often doesn’t.
- That I would be this suspicious when the tests pass on first try, and have to invert my assertions to force a test failure and convince myself that things are working as intended. (Aside: Why is this not a standard feature of testing frameworks? I want some way to re-run tests flipping some of the assertions, to make sure they are testing what I think they are.)
- That appropriate use of emojis would become such an important communication skill.
- That it is all people, all the way down. They are (mostly) lovely, and not nearly as hard-shelled as turtles.
What is something that surprised you about working as a software engineer?
Originally published on https://anaulin.org/blog/.
Top comments (75)
So true.
It's a little bit like voodoo sometimes. I can see why a lot of people rather do back-end. I learnt much most of what I know about CSS from StackOverflow than from books, good thing now there's MDN. Not entirely sure where to start when juniors ask me "how do I learn CSS".
Totally.
Yes! There is a weird relationship between these two observations: building cross-browser UIs and writing solid CSS is hard, and yet some places in the industry doesn't seem to value frontend engineers as much as backend engineers.
I wonder if there is something about how good UIs are, at its core, a more people-centric part of the software and, as such, are somehow seen "less technical" and thus less valuable. Point #8 in the list all over again! 🤔
I decided to subvert this trope and became a front-end engineer after years of desktop and back-end development. And indeed I discovered a few things.
Most programmers don't believe they need a front-end. Only market-oriented project managers do.
The perceived lack of appreciation often stems from dire shortage of competent UI specialists. Programming "in jQuery" is easy, but writing good, efficient, responsive, intuitive and resilient UI is just as thought-intensive as implementing a complex algorithm. And, unfortunately, 99%* prospective employees can't handle simple asynchronous funnels without drowning in callback hell. It's a skill best acquired writing multi-threaded C code, which most front-end developers never did.
The salary is often low when the management compares expectations of a competent engineer with the aforementioned 99%, which know not to ask for much.
In the end, that's why only a few companies have products with stellar UI. And this spark is lost the moment some new "efficient manager" decides to outsource or otherwise downplay the importance of good UI.
Yeah, interviewing for front end engineers is really tricky. I mostly ask for code walkthrough of portfolio projects, but most don't have the complexity of real world projects.
And you're right, there's a lot of async logic going on on the UI for complex apps. In my experience, that's hard to grapple for a lot of programmers, frontend and backend. And before modern frameworks like React, Vue, making sure the the UI properly handles update events being dispatched from multiple sources, resolving race conditions, and updating the view correctly is difficult, it was hard not to end up with spaghetti code. It's a good thing I learnt to do a bit of video game programming in a side project, and took some of lessons learned there and applied it to front-end engineering on the web. Video games UIs are super sophisticated, but proper modelling of object and events can go a long way in to keeping things sane and maintainable. At least now we have modern frameworks to help.
People who say frontend is easy are usually thinking it's just HTML but that's not true. There's security, storage, cache management, performance, user experience and much more to deal with.
That is true, but at least 95% of all web applications do not need this. I’ve worked on a couple that had really complex React front ends that absolutely did not require them. It just resulted in hard to maintain code, all because management wanted to use a hip framework.
There is probably only one author who tries to explain the voodoo of CSS logically, from the specs - and that's Eric Meyer. I liked his book "CSS: The definitive guide" a lot, but it used to not cover the newer css stuff (probably the newer version does to some extent).
I would definitely like a solid chapter (or blog or whatever, with Eric Meyer-ish details) on flexbox and CSS grids.
Ooo, shall check that out! 👍
Try Shadow DOM. It eats compound selectors for breakfast.
Lets Build Web Components! Part 1: The Standards
Benny Powers
I thought only I did this! haha
Fun fact: someone taught me that early on in my career as a best practice to make sure that my tests were actually doing something.
These days I try to always start by writing my test with an assertion that is guaranteed to fail, run the tests, verify that it does indeed fail, then rewrite the test to pass.
Test Driven Development practitioner (I'm not) would probably sigh (at least) reading this. According to TDD you should first write your failing (obviously) test, and then write the code that would make this test pass. This way, checking that tests are actually doing something is part of the workflow.
Your list is great :-) I'm possibly old and cynical these days but I'd maybe add '...and nothing seems to be getting much better'.
On the testing side - I've recently started running 'mutation tests' on my code (infection.github.io/ in particular). It's been quite eye-opening and a little depressing watching it flip 'true' to 'false' all over the place and tests still passing :-/. In my (feeble) defence, a lot of the time it's because in one test I'll be checking that related-fieldX has changed the way I expect and in another checking the true/false aspect - but it's still pretty eye-opening and has caught a lot of things I'd otherwise have missed :-)
...or stryker-mutator.io
When I'm assigned a bug and there's not unit test that covers it, the first thing I do is write the test that fails, and then go about fixing it. And usually along the way discover additional cases that would cause similar failure that hadn't been covered yet.
Or delete some parts of the implementation and see if some tests fail. I sometimes split commits in test and implementation so I see failing pipeline.
My workflow is almost always:
That’s why you should
check out the mutation testing comments below, very helpful tactic to validate tests. Who guards the guards?
that's fucking right hahaha
That working in IT is just this: Solving algorithmic problems is by far easier than solving people problems. While you learn the first in shool, you have to learn the latter at work - the hard way.
Explaining complex things using simple language.
If you are not working in a scientific environment, you must be prepared that your customer, project manager, stakeholder or whoever you will communicate technical decisions with did not spend hours for analysis and PoCs and they might not have technical background.
This is also tightly connected to abilities like public speaking, argumentation, discussion, empathy and other personal traits/soft skills.
One thing that surprised me a lot is when I realized that at the beginning of my career I was able to learn a lot just from experience but after some long time (around 10 years) I need to dedicate some study time or to use different technologies.
Ah, that's so true. The learning curve does flatten out, somehow, if you don't put effort into it.
Be the kind of person that will take a risk to fix something , even if you break it . Fixing it once you break it makes you feel pressure and the next time something happens you are the first to be called .
That meetings will eat up a significant portion of your day, and will always happen right when you are in the middle of "the zone".
That a marketing/sales VP will comment in said meeting "but it's just software" as an argument why you should re-factor the entire code base.
Great post!
To me that's more of an ideal situation. More often than not I encounter code bases were there's barely any automated tests at all. To be fair, in 80% of these cases that's because there's no unit test framework available
@anaulin , you made the latest issue of TLDR newsletter. I just saw it in my inbox :D - tldrnewsletter.com/archives/20181113
😊 Thanks for letting me know!
You also made last's week High Scalability's "Stuff the Internet says on scalability": highscalability.com/blog/2018/11/1...
Another thing to add is that all code is ephemeral (to some degree). I used to be very protective of stuff I wrote, like it was some final product. But it never is. Someone will always modify, fix, or completely throw it away. Best advice I got was from a coworker at my last job when he was leaving which was 'take ego out of your code' and I've been a lot less stressed out.
Also good code review is key.
'Take the ego out of your code' is good advice.
Some code ends up being temporary or modified soon after its created and other code ends up running in production for decades. And how long the code lives isn't really predictable in many cases.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.