DEV Community ๐Ÿ‘ฉโ€๐Ÿ’ป๐Ÿ‘จโ€๐Ÿ’ป

DEV Community ๐Ÿ‘ฉโ€๐Ÿ’ป๐Ÿ‘จโ€๐Ÿ’ป is a community of 967,611 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Ana Ulin ๐Ÿ˜ป
Ana Ulin ๐Ÿ˜ป

Posted on • Updated on • Originally published at anaulin.org

Things Nobody Told Me About Being a Software Engineer

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:

  1. That it is normal to have more lines of tests than production code.
  2. That having no choice but to use vi early in my career would mean that I can never leave those keybindings behind.
  3. 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โ€.)
  4. 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.)
  5. That writing code is only a small part of what goes into shipping production software.
  6. 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.
  7. 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.
  8. That having decent people skills makes my technical skills suspect, in the eyes of some.
  9. That learning to manage my own energy and mindset is the most important skill through gnarly debugging and hairy code reviews alike.
  10. 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.
  11. 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.)
  12. 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.
  13. That CSS is the most complex modern programming language.
  14. That internships should always be paid at market rate.
  15. 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.
  16. 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.
  17. That the best technology doesnโ€™t necessarily win. In fact, it often doesnโ€™t.
  18. 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.)
  19. That appropriate use of emojis would become such an important communication skill.
  20. 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 (76)

Collapse
 
shiling profile image
Shi Ling

That CSS is the most complex modern programming language

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".

Collapse
 
shiling profile image
Shi Ling

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.)

Totally.

Collapse
 
anaulin profile image
Ana Ulin ๐Ÿ˜ป Author

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! ๐Ÿค”

Thread Thread
 
yes_we_cat profile image
e-neko

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.

  1. Most programmers don't believe they need a front-end. Only market-oriented project managers do.

  2. 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.

  3. 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.


  • based on personal experience interviewing people. yes, it's that bad.
Thread Thread
 
shiling profile image
Shi Ling • Edited on

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.

Thread Thread
 
suprnova32 profile image
Patricio Cano

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.

Collapse
 
bendtherules profile image
Abhas Bhattacharya • Edited on

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.

Collapse
 
shiling profile image
Shi Ling

Ooo, shall check that out! ๐Ÿ‘

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ
Collapse
 
ruvans profile image
Ruth Evans

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.

I thought only I did this! haha

Collapse
 
anaulin profile image
Ana Ulin ๐Ÿ˜ป Author

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.

Collapse
 
furgas profile image
Tomasz Sawicki

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.

Collapse
 
ohffs profile image
ohffs

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 :-)

Thread Thread
 
skyboyer profile image
Yevhen Kozlov
Collapse
 
smallbellows profile image
Sara Given

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.

Collapse
 
kyslik profile image
Martin Kiesel

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.

Thread Thread
 
uzitech profile image
Tony Brix

My workflow is almost always:

  1. Write the code
  2. Write the test
  3. Run passing tests
  4. Comment out the code
  5. Run failing tests
  6. Uncomment code
Thread Thread
 
stealthmusic profile image
Jan Wedel

Thatโ€™s why you should

  1. Write a failing test
  2. Make the test green by implementing
  3. Refactor Go back to 1.
Collapse
 
sturzl profile image
Avery

check out the mutation testing comments below, very helpful tactic to validate tests. Who guards the guards?

Collapse
 
darwinv profile image
Darwin

that's fucking right hahaha

Collapse
 
thomasjunkos profile image
Thomas Junkใƒ„ • Edited on

What is something that surprised you about working as a software engineer?

That it is all people, all the way down. They are as cute as turtles, but donโ€™t have hard shells.

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.

Collapse
 
rapasoft profile image
Pavol Rajzak

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.

Collapse
 
nflamel profile image
Fran C.

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.

Collapse
 
anaulin profile image
Ana Ulin ๐Ÿ˜ป Author

Ah, that's so true. The learning curve does flatten out, somehow, if you don't put effort into it.

Collapse
 
sjehutch profile image
scott hutchinson

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 .

Collapse
 
dougaws profile image
Doug

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.

Collapse
 
smuschel profile image
smuschel • Edited on

Great post!

That it is normal to have more lines of tests than production code.

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

Collapse
 
rhymes profile image
rhymes

@anaulin , you made the latest issue of TLDR newsletter. I just saw it in my inbox :D - tldrnewsletter.com/archives/20181113

Collapse
 
anaulin profile image
Ana Ulin ๐Ÿ˜ป Author

๐Ÿ˜Š Thanks for letting me know!

Collapse
 
rhymes profile image
rhymes • Edited on

You also made last's week High Scalability's "Stuff the Internet says on scalability": highscalability.com/blog/2018/11/1...

Collapse
 
jweboy profile image
Jweboy • Edited on

That CSS is the most complex modern programming language

I very much agree this point . Css is easy to get started, but mastery is very difficult.As a front-end developer, I also found this to be a big problem, but fortunately I focused on javascript.

Collapse
 
jeyj0 profile image
Jannis Jorre • Edited on

To #18: Search for mutation testing - it's not exactly what you want, but it's very close! ;)

Great collection btw!๐Ÿ˜‡

Collapse
 
bgadrian profile image
Adrian B.G.

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.

I think the statement is half true, as in the size of the company is not a causality, but more of a self marketing, laziness/careless and other issues.

I actually read some poll results with thousands of answers and I still did not find something to confirm or deny this. I personally know startup devs that earn way more than most corporate, even with "inferior" languages.

I think most of the times the devs do not know how to sell them, they do not look for new opportunities all the time, accept low pays, and the big companies have preset levels of compensations that level things out.

Most of the corporations are overrated, at least in my country they do not pay (too much) more than an avg company. Also most of the times you are not doing the same job, on startups you work harder and cover more areas, so probably you will work less and earn more in a corporation :))

My statements are for mid-senior web developers.

Collapse
 
shaunagordon profile image
Shauna Gordon

I think you're giving corporations too much credit. That may be due to differences in location.

Here in (my part of) the US, the big corporations often pay less, because it's what they could get away with, especially through the recession. With the healthy startup economy around here, that's starting to change, but I've got more than a few stories of people who are/were in a big company, got moved around and restructured to the point that moving even to an early-stage startup would result in less work and higher pay. In one extreme, I know a person who had to be replaced by seven people after he left (when the company refused to give him one person to offload some of the work to).

Collapse
 
foresthoffman profile image
Forest Hoffman

Number 8 is such a shame, because of how important those soft-skills are! ๐Ÿ™„

Collapse
 
xristocodos profile image
Xristo

I have a very mixed background, that even though technical, is well-traveled, and the by-product of readapting to different personality types and backgrounds is social skills, which I sadly sometimes have to dampen severely by saying the bare minimum) just to be believable for interviews.

Otherwise you come off as the Nelson Bighetti "great guy, terrible coder" type they're already afraid of accidentally recruiting...smh irony's funny until it isn't.

Collapse
 
kylemay profile image
Kyle May

Same thing happens to all military veterans as well. We have to never bring up our experiences because then every criticism or idea will be perceived as less intelligent or overly aggressive by management.

Collapse
 
foresthoffman profile image
Forest Hoffman

Having to hold back when it comes to personality on the job is very stressful and demoralizing. I'm sorry to hear that.

Collapse
 
giorgosk profile image
Giorgos Kontopoulos ๐Ÿ‘€

@Xristo is this country/culture related that you have to be a different you around some ?

Collapse
 
ozzyogkush profile image
Derek Rosenzweig

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.

Collapse
 
bosepchuk profile image
Blaine Osepchuk

'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.

Collapse
 
everydaymemes9 profile image
Everyday Memes • Edited on

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.

When android studio initially added support for unit tests, there was a bug where all tests would pass no matter what.

It was an important lesson: all software is written by random people on the internet, treat it as such.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

๐ŸŒš Friends don't let friends browse without dark mode.

Just kidding, it's a personal preference. But you can change your theme, font, etc. in your settings.

The more you know. ๐ŸŒˆ