I love it when a seasoned developer feels compelled to get a bit retrospective and share advice that they’ve had to learn the hard way in their careers. It often gets a bit philosophical and sometimes a bit Reader’s Digest-y in an endearing way, like something that would make a funny cross-stitching someday.
Here’s Baldur Bjarnason in 136 facts every web dev should know before they burn out and turn to landscape painting or nude modeling:
27. Minimalism is garbage. Simplicity is great, but minimalism sucks. Everything you see on the screen should have a reason to be there (be an embodiment of ‘doing’), but if the reasons are complicated, then the design should represent that complexity. Hiding complications makes everything harder, and excessive minimalism is just as harmful as excessive decoration.
I especially like it when they have that baby bear’s porridge feeling to them. Like Baldur probably lived through phases where he built (or was on a team that built) interfaces that were just too complicated (too hot!!). Then fought against it by building interfaces that were so simple they hid any semblance of complexity (too cold!!). Then came around to just trying to make things clear and as simple as possible while still embracing the idea that complexity can be what makes software valuable.
36. Naming things is fantastic. Everything on the screen should have a name. It’s better for your work. It’s better for accessibility. It’s better for your design. Take a table view and name it ‘Inbox’, ‘Screener’, or ‘Paper Trail’, and they suddenly mean something. What you do with them has changed. A good name transforms design and action.
Hear hear! Personally, I like to go so far as that, whenever possible, the name that we pick is used in the interface, in the documentation, what we use as a team internally when we talk about it, and in the code itself. Not just the front-end code, but in the API and database as well. Make those names really meaningful.
Maybe a bit of both?
Justin Etheredge got reflective recently as well in 20 Things I’ve Learned in my 20 Years as a Software Engineer:
6. Sometimes you have to stop sharpening the saw, and just start cutting [stuff]. Some people tend to jump into problems and just start writing code. Other people tend to want to research and research and get caught in analysis paralysis. In those cases, set a deadline for yourself and just start exploring solutions. You’ll quickly learn more as you start solving the problem, and that will lead you to iterate into a better solution.
I feel this one because I’m on a team right now that has a lot of people who pull in different directions on this. I’m a “cutting stuff” kinda guy. Push push push to get started working on things, get that dopamine hit that this kind of “productivity” provides, and feel like you’re closer to the finish line. But I get us into trouble. I cause technical debt. I cause bugs. My co-founder, who gets an incredible amount of work done but that I’d still qualify as a saw sharpener, has pulled me back and balanced us the last few years into a better place. We can’t pull too far though, to Justin’s point. There is still a lot of value in just getting in there.
It ain’t just for bugs
Kitty Giraudel did a bit of recent reflection as well in 30 Frontend Tips. It’s a slightly cheeky title in that most of the advice isn’t specific to the front end.
10. Debugging is a skill to learn. It takes time, it takes practice. It starts by reading error messages, and learning what to Google. It gets easier with time, and is a useful (necessary?) skill to grow. Don’t get frustrated if you struggle, especially at the beginning.
Ain’t that the truth? I’d almost say that most development work, at some point, becomes debugging. Especially because it’s not always “fix a bug”, it’s “I need to do this task, but I need to learn how this part of the site works for me to do the task”. So you’re essentially debugging at first in order to load that area of the site into your brain, then you do the task. Which might even be something seemingly opposite to debugging like feature development. The skillset is largely the same. It involves reading code, following data as it moves around. Logging and breaking to assist your understanding of where and how things happen.
#1 is pretty good too:
1. Learn what you want. There is enough to learn for a lifetime, so don’t feel like you have to follow the hype. Frameworks and libraries come and go, fundamentals remain, so I would recommend focusing on HTML, CSS and JavaScript if you get to choose (and do frontend).
The thing about fundamentals is that they last. As much as tech has changed in my career, the deep basics of the three classics (HTML, CSS, and JavaScript) have always been there and it feels more and more like they always will be. It doesn’t mean you have to start there. Most don’t, I would guess. I sure didn’t. But finding your way to those fundamentals is a smart move.
That writing thing again
I gotta include this one from Ngoc Vuong from a few years ago in My lessons of 3.5 years being a front-end developer:
I have realized that maintaining a technical blog makes me become quite more competent in programming. Why is that? Because in order to write a decent technical blog, I need to do a lot research, reading and dedicate a certain amount of time to turning my understanding into words in as simple way as possible. It is very time-consuming, but I find it is worth my time for the reason that I have retained the knowledge better.
Don’t blog for the glory, blog for the cemented brain nuggets.
