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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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 :))
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).
To #18: Search for mutation testing - it's not exactly what you want, but it's very close! ;)
Great collection btw!😇
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.
You should take a look at Mutant in ruby world! It's awesome!
Anyway, great post!
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 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.
This 🙌
Liked the list!
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...
I take this even beyond. For me, tests are production code.
Great intakes! Thanks for sharing. :)
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 this
. But hats off to design, front end, and testers.
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...
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.
30+ years in...
15, oh goodness, #15.
So much truth here each point could easily take up a book worth of discussion.
Keep it up.
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!
I can definitely relate to this. Can you expand more upon this based on your experience.
So true. Love it!
Typo on 19. You said “suck” but I think you mean “such”. Great article, thanks for writing!
Thanks for catching. Fixed!
So true
Everything except this. To be fair my experience with PHP has been entirely maintaining other developers’ code but one of my least favourite languages.
Nailed it :)
For point 18 there is, google mutation testing. There's 1 or 2 mutation testing frameworks I've seen that are pretty cool.
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.