As software developers, we need to consume a lot of information in order to improve at our craft. While running dev.to, I read a lot about software. I wanted to share three pieces that have had an effect on me.
“Just put a form up to collect their e-mail…”
“Just make it so they can login with Facebook…”
“I’ll just throw it in a new database field.”
“We can just launch a new database server…”
“Lets just let them post notes, like Twitter does…”
This article, about the use of the word "just", stood out because I immediately realized that I had this problem. When I wanted to push an idea through, I'd say "just do this", but resented someone taking that approach with me.
This concept, which I have since seen described in other metaphors, such as hacker vs mathematician, has had a huge impact on how I look to assemble a team. The right balance between makers and menders on a software project is a critical component of success. I ask potential candidates where they fall on this spectrum and it is always an illuminating conversation. Regardless of where you fall in this range, it is critical to recognize, respect, and seek out the other type.
This post describes really well the purpose of comments in code. In my universe of languages and problems, it applies very well. The part of software development where we need to work together and hope to scale these complex systems somehow it is always helpful to receive some guiding light about how to best do that.
There are many more posts that could have made it into this small list, but I'll leave the next three for a follow-up post.
Happy coding. â¤ï¸
Top comments (3)
Great list - all of these articles are excellent. There's loads of gold in dev.to!
I also love how something you read on the internet can have a long-term change to your approach like this. Like personally, I used to over-use the word "guys", right up until I joined the
Elmcommunity Slack. The Slackbot on that channel gently reminds you that words like "guys" can lead to people feeling excluded, and that you should consider inclusive alternatives instead. After seeing that one time it was like "Yep, can't argue with that". That's why my article "Thinking Of The Next Developer" was named as such, rather than "Thinking Of The Next Guy" (which would have been a snappier but less inclusive title).I genuinely love how much it feels like everyone is constantly levelling each other up in dev communities, in all sorts of areas. <3
All three articles have great advice!
Most interesting to me though is how non of the selected articles are about technical details. The most challenging part of our job is not the writing of code after all.
I wish more people would realize this instead of fighting language|editor|framework wars 🤘
nice