When starting as a software developer, everything seems like magic, compilers, IDEs, networking, kernels, etc. While we can ignore how these things work, to really grow as a developer, the magic must be removed. At the end of the day, our job is to produce something that works, having a well-rounded knowledge of how the full stack works can help you to understand when weird stuff happens, and come up with useful theories as to what is going on. Much as when I was a kid, I tended to take things apart to see how they work, and most times was able to get it back together; apologies to my Dad for the barometer/thermometer pieces he found one day. Here are a few things you might consider doing to “take things apart” and remove the magic.
I started my professional career with a Pascal program (I know that dates me a bit) and then continued with C and C++ and discovered Python around version 1.4 and used it heavily for over ten years, and really didn’t like Java when I first met it (version 1.3-1.4 time frame).
I’ve also used a ton of other languages for real deployed projects, like Python, Ruby, C, C++, Common Lisp (which I <3 love), C#, Clojure, Visual Basic, and Go, so I’m a not the average “blub” programmer saying this.
But since about 13 years into my career, it’s become my tool of first choice for most things.
I’ve not done a ton of programming in Python for a while, but I still do like the language. I also like trying to do things in one line (ok, one statement), just because it’s a bit more difficult :). These are pretty old, but I used to keep these in my email signature line…
AKA Good Programmers Are Doing Real Science
There are a bunch of long-ish winded definitions of the scientific method, but I think a reasonable pithy description would be:
- Come up with a theory to explain an existing phenomena.
- Use that theory to come up with a falsifiable prediction.
- Conduct experiments to prove or disprove the truth of the prediction.
- Independent parties repeat #3 and reproduce the results.
When dealing with the problem of a long method, the simplest thing you can usually do is to break it into it’s conceptual pieces and have a series of tail called functions that call the next chunk of the computation.
So given this:
1 2 3 4 5 6
In The Cult Of Abstraction I railed against the over-use of abstraction. Here, I want to talk about a particular source cause of over-abstraction I have seen (and been guilty of).
While I’m often at odds with software frameworks (libraries are to be preferred over frameworks, generally), I’ve found that process frameworks can be very good indeed, when done right. Implementors of agile methodologies ironically can fall into the trap of doing it wrong.
I’ve known handywrite shorthand for a number of years, and finally decided that I should learn shorthand proper, ideally with the best bang/buck ratio, as well as minimal amount of initial learning, with being able to ramp up the amount I learn later, as time permits. I settled on Gregg shorthand, Anniversary Edition.
(see here for the full Agile Organizer series)
If you do Agile, it’s probable that you do something called a retrospective. At least in the ones I’ve been involved with, there’s usually a part where we go over what’s going well, and what could be changed. With the agile organizer, I’ve found that periodically doing retrospectives about the way I am using it is useful and worthwhile. If you use it, I hope you would too.