We should think of our code, even our designs, as running for decades, and alter our work to match.
JS is also global by default. We use IIFEs and wrapper functions to add scope.
Don’t build more JS than you can maintain over the long term. If you’re going to be building something for a long time, make sure what you are building will grow with you. Make sure you don’t depend on other people’s work too much, lest you want to keep refactoring your code when the framework you picked goes out of style.
We construct top-10 lists for movies, games, TV—pieces of work that shape our souls. But we don’t sit around compiling lists of the world’s most consequential bits of code, even though they arguably inform the zeitgeist just as much.
This is a fascinating way to look at the history of computing, by focusing in on culturally significant pieces of code. The whole list is excellent, but if I had to pick a favourite …well, see if you can guess what it is.
A handy translation of git commands into English.
- Plan your scripts out on paper.
- Stop obsessing over tools.
- Focus on solving problems.
- Maintain a library of snippets that you can reuse.
I love the way that Amber is documenting her journey—I think this is so useful for others making the progression from junior to mid-level developer.
A bit of a tangent, but I love this description of reading maps:
Map reading is a complex and uniquely human skill, not at all obvious to a young child. You float out of your body and into the sky, leaving behind the point of view you’ve been accustomed to all your life. Your imagination turns squiggly blue lines and green shading into creeks, mountains, and forests seen from above. Bringing it all together in your mind’s eye, you can picture the surroundings.
When you ever had to fix just a few lines of CSS and it took two hours to get an ancient version of Gulp up and running, you know what I’m talking about.
I feel seen.
When everything works, it feels like magic. When something breaks, it’s hell.
I concur with Bastian’s advice:
I have a simple rule of thumb when it comes to programming:
less code === less potential issues
And this observation rings very true:
This dependency hell is also the reason why old projects are almost like sealed capsules. You can hardly let a project lie around for more than a year, because afterwards it’s probably broken.
See how an Enigma machine works …and interact with it.
Letters to be encrypted enter at the boundary, move through the wire matrix, and exit.
I love React. I love how server side rendering React apps is trivial because it all compiles down to vanilla HTML rather than web components, effectively turning it into a kickass template engine that can come alive. I love the way you can very effectively still do progressive enhancement by using completely semantic markup and then letting hydration do more to it.
I also hate React. I hate React because these behaviours are not defaults. React is not gonna warn you if you make a form using divs and unlabelled textboxes and send the whole thing to a server. I hate React because CSS-in-JS approaches by default encourage you to write completely self contained one off components rather than trying to build a website UI up as a whole. I hate the way server side rendering and progressive enhancement are not defaults, but rather things you have to go out of your way to do.
And if you want to adjust the front-end code, you’ve got to set up all this tooling just to change a
div to a
button. That’s quite a barrier to entry.
In elevating frontend to the land of Serious Code we have not just made things incredibly over-engineered but we have also set fire to all the ladders that we used to get up here in the first place.
I love React because it lets me do my best work faster and more easily. I hate React because the culture around it more than the library itself actively prevents other people from doing their best work.
I find myself doing pseudo code before I write real code, sure, but I also leave it in place sometimes in code comments.
When people talk about learning React, I think that React, in and of itself, is relatively easy to understand. At least, I felt it was. I have components. I have JSX. I hit some hiccups with required keys or making sure I was wrapping child elements properly. But overall, I felt like I grasped it well enough.
Throw in everything else at the same time, though, and things get confusing because it’s hard at first to recognize what belongs to what. “Oh, this is Redux. That is React. That other thing is lodash. Got it.”
This resonates a lot with Dave’s post:
React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.
Lots and lots of programming advice. I can’t attest to the veracity and efficacy of all of it, but this really rang true:
If you have no idea how to start, describe the flow of the application in high level, pure English/your language first. Then fill the spaces between comments with the code.
Blogging about your stupid solution is still better than being quiet.
You may feel “I’m not start enough to talk about this” or “This must be so stupid I shouldn’t talk about it”.
Create a blog. Post about your stupid solutions.
This is a wonderfully written post packed with hard-won wisdom.
This are the myths that Monica dispelled for herself:
- I’m a senior developer
- Everyone writes tests
- We’re so far behind everyone else (AKA “tech FOMO”)
- Code quality matters most
- Everything must be documented!!!!
- Technical debt is bad
- Seniority means being the best at programming
fopenwhen you can write
throwVE. Call that name
fct. That’s German naming convention. Do this and your readers will appreciate it.
Today was a good day …and here are the very good photos.