Things Nobody Told Me About Being a Software Engineer

Ana Ulin 😻 on November 09, 2018

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 w... [Read Full]
markdown guide
 

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

 

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.

 

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.

  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.

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.

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.

 
 
 

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

 

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

 

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:

  1. Write the code
  2. Write the test
  3. Run passing tests
  4. Comment out the code
  5. Run failing tests
  6. Uncomment code

That’s why you should

  1. Write a failing test
  2. Make the test green by implementing
  3. Refactor Go back to 1.
 

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

 
 

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.

 

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.

 

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 .

 

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.

 

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!

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

 

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

 
 

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

 

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.

 

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.

 

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

Great collection btw!😇

 

Number 8 is such a shame, because of how important those soft-skills are! 🙄

 

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.

 

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.

 

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

 

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

 

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.

 

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

 

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

You should take a look at Mutant in ruby world! It's awesome!

Anyway, great post!

 

Nice article, I'm surprised that you have started programming at a age of 7, would like to hear more about it. I have written about my own experience in being software developer if you would like to see it here it is: megablog.site/2019/06/11/what-is-a...

 

That you don't need to be a math genius to be a programmer.

That CS != programming.

If I knew that in school I'd have started to pursue this direction much earlier.

 

That having decent people skills makes my technical skills suspect, in the eyes of some.

This 🙌

Liked the list!

 

What surprised me the most is that every company is selling the exact same work with such praise but in the end everyone just builds exactly the same with different names and user interfaces.

Also shocking: for all the complex topics covered while studying, the actual work always boils down to the same simple Tasks with literally no difference in any programming language because the systematic Always is identical.

 

Alternatively: that good frontend and test automation specialists are grossly undervalued.

Pretty much. And this is coming from somebody who is 100% back end, and when asked what kind of developer he is responds: I can make just about any system work well with the best of them. But I am a trainwreck at making them look any more than terrible. Front end and test folks have such a difficult job because their code needs to be written in an aesthetically pleasing way, and continue to be so when it runs. I actually wrote a post about thishere. But hats off to design, front end, and testers.

 

That having no choice but to use vi early in my career would mean that I can never leave those keybindings behind

And that's why I use vim inside phpstorm 😅😅

 

Re number 18: What a great idea!

I'm the dev for Ruby gem minitest_log (code is on GitHub). I've added your idea to my list of enhancements!

 

That's a great Article Ana, everyone should know about these points. I found this article pretty informative so I mentioned it in my blog: megablog.site/2019/06/11/what-is-a...

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

I take this even beyond. For me, tests are production code.

Great intakes! Thanks for sharing. :)

 

Because I junior developer I'm interested in similar articles and it was realy useful to know some things, thanks;)
So, any developer needs to have a dreat CV and I want to recommend resumeyard.com/cv-writing/ where profesional cv writers can do this.

 

So true

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.

 

Typo on 19. You said “suck” but I think you mean “such”. Great article, thanks for writing!

 
 

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.

30+ years in...

 

You forgot #1, which took me years to learn:

How to say NO.

 

Oh yes! Let’s make number 18 happen for the love of everything!

 

That having decent people skills makes my technical skills suspect, in the eyes of some.

I can definitely relate to this. Can you expand more upon this based on your experience.

 
 

15, oh goodness, #15.

So much truth here each point could easily take up a book worth of discussion.

Keep it up.

 
 

For point 18 there is, google mutation testing. There's 1 or 2 mutation testing frameworks I've seen that are pretty cool.

 

PHP is cool again

Everything except this. To be fair my experience with PHP has been entirely maintaining other developers’ code but one of my least favourite languages.

 

I don't know if I can ever truly enjoy PHP. A lot of the things in it are a bit too inconsistent for me. Also it makes me hit the shift button too much, it hurts my pinky 😂

 

Am beginner in Python and i really love what you just wrote. I want to be good at software building and creating good working space with teams. What will you advice.

 
Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

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.

 
Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

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.

 
Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

I am very curious to know how gender, ethnicity and wardrobe affect the perception of someone's code.

 

Study finds gender bias in open-source programming

Basically PRs submitted by women are more likely to be accepted if the gender is not known. If the gender is known, then they are less likely to be accepted.

"Our results indicate that gender bias does exist in open-source programming," Murphy-Hill says. "The study also tells us that, in general, women on GitHub are strong programmers. We don't think that's because gender affects one's programming skills, but likely stems from strong self-selection among women who submit pull requests on the site.

 

Just one remark here, there is (at least in my city) one woman programmer per 10 men programmers. I suspect that this might be a part of the reason why there are less woman PRs than mans PRs, if we were equal in number (and should be) this study would be relevant, but right now I don't think that it represents the correct situation fully.
Also, the differences here was -4.1% for all female pull requests, -3% for identifiable female pull requests, and +5% for non-identifiable female pull requests.

Those are pretty small differences.

I suspect that if you compared two subsets of the data with some obviously irrelevant characteristic such as men with beards and men without beards, you'd find the same statistical fluctuations.

If we were studying particle physics this large an effect would be relevant, but people are more complex than particles. A 3, 4, or 5% variation in behavior could be a mostly random chance.

Opinion polls are taken with samples of 1000 people usually have margins of error of about the same magnitude as the "bias" found in this study.

Hi Darkø, fair point.

But I think there is valid data in there: 58% of acceptance rate if you are easily detectable as a woman, against 70% of women with gender neutral profiles. That's outside the range of error.

One study is not enough to make an iron clad case but if you measure it against women's experience (just talk to them) you'll notice a pattern of their gender being a factor in perception.

And it seems to be happening also to trans men:

I know, a few cases don't make a fool proof opinion, but if you check dev.to/t/shecoded you'll quickly notice a pattern of women being judged as less worthy "just because"

[deleted]

So you'd trust an anecdote over real data and studies?

The lack of empathy inherent in "I haven't personally experienced ______ so it doesn't exist" is deeply upsetting, really.

Well the article implies the author learned all this stuff through experience. It isn't titled "Things I read about in reports about the IT industry"

Also I said I have not heard of ONE case of this happening outside of "studies". Even one.

So again: if it didn't happen to you personally, it doesn't happen to anyone. Makes sense.

code of conduct - report abuse