Often software developers are encouraged to learn deeply. Know your language and framework of choice better. That’s all good, but there’s another side to learning that’s often overlooked. Knowing a little about a lot of things so you have less blind spots.
In the blog post we look at the importance of learning broadly and how to go about it.
You gently face-palm and let out a groan. Your bug is so obvious now. How did you miss it before? Thank goodness you didn’t blame Bob publicly.
In this blog post we will look at how to get unstuck with things you do not understand (yet). It’s a methodical approach to solving insight problems - problems where all the information is known but you need to see it a different light to solve it. We start from writing down the problem and move through increasingly more esoteric phases such as changing location to invite insight in.
Ain was born out of the frustration of working with many API endpoints in GUI clients.
While pretty, I could’t use any shell-scripts or commands such as uuidgen as input to the endpoints without copy pasting from a terminal. And I had to copy-paste the resulting output back into the terminal to further slice and dice it.
I had become a human pipe and my ctrl+c, ctrl+v fingers were hurting. By using curl and/or httpie for the heavy lifting, Ain removes you from the piping of input and output. With Ain, you can:
You sigh. Maybe the compilation didn’t work? You recompile and run it again. Nope. Still the same problem. You stare out the window.
This post is about ways of getting unstuck on a problem when you do not (yet) have all the relevant knowledge. It focuses on the problem with the ego when being a more seasoned programmer and the difficulty on admitting that you don’t know (yet).
From there we go through the steps on being unstuck and making that ego more inflated and annoying.
“The tests are timing out again!”, someone yells. “Alright I’ll bump them”, you instinctively respond. Then you pause and feel uneasy. Is there another way?
In this blog post, I share my growing disconnect with code-coverage and unit-testing. I then detail the method I’ve been using for the greater part of 7 years and how it still allows me to preach at length that being correct is the single most important thing for a developer.
Jonas Lundberg:
We all do it. Up to many times a day and yet it’s rare that I meet someone that has given it a second thought. No, it’s not secretly snacking chocolate from your top office drawer.
It’s how you write and structure your commits. Possibly while snacking chocolate.
What follows is a piece marrying atomic commits (as in small commits with one focus) with Donald Knuth’s literate programming. It ends with some research on whether or not this practice commonplace on the 100 most popular GitHub repos.
Knowing the architecture of an application is like passively knowing a foreign language. When you speak it - it’s awkward. Here’s how you go from passively to actively owning a code-base.
Jonas Lundberg:
In order to know that you are progressing you need some yardstick to measure against. The most common case is someone better and more experienced (having done the trip to mastery themselves) telling or showing you what you need to improve or if you are doing great. But what if there are no coaches or obvious roads to mastery?
From there Jonas goes on a deep-dive on why feedback loops are important and how you can acquire them for yourself. Oh, and if you need a feedback loop (and perhaps some cheer leading) on your writing, join the #blogging channel in our Community Slack. We have a small group forming.
Jonas Lundberg:
Hands on tips for learning a new codebase within a short time frame enough to be able to say: “Steve’s legacy ends here. I’ll figure it out.”
This is a great piece filled with actionable details and particulars.
