Much of the essence of building a program is in fact the debugging of the specification. –Fred Brooks, No Silver Bullet (1986)
Urgency makes for inflexible minds. –Jamie Holmes, Nonsense: The Power of Not Knowing
If a human is more important than technology, the technology must work in a human way. –Steve Wozniak
Our life is frittered away by detail. Simplify, simplify. –Henry David Thoreau
Fostering an atmosphere that doesn’t allow for error simply makes people defensive. They don’t try things that may turn out badly. You encourage this defensiveness when you try to systematize the process, when you impose rigid methodologies so that staff members are not allowed to make any of the key strategic decisions lest they make them incorrectly. The average level of technology may be modestly improved by any steps you take to inhibit error. The team sociology, however, can suffer grievously. –Tom DeMarco and Tim Lister, Peopleware: Productive Projects and Teams
You don't really know who you are until you've faced real adversity. –Dan Gasby
By far the most common mistake is to treat a generic situation as if it were a series of unique events; that is, to be pragmatic when one lacks the generic understanding and principle. The effective decision-maker, therefore, always assumes initially that the problem is generic. He always assumes that the event that clamors for his attention is in reality a symptom. He looks for the true problem. He is not content with doctoring the symptom alone. –Peter F. Drucker, The Effective Executive (1967)
If you’ve worked in development for any length of time, you’ve heard about how “visual programming” will make writing code with a text editor obsolete. Personally, I feel like this idea falls into the same class as “snake oil”. This author has a similar view and discusses some of the limitations that prevent visual languages for making much project. Nevertheless, he thinks that visual languages will become viable eventually, but it’ll be a long time.
http://www.outsystems.com/blog/2015/03/visual-programming-is-unbelievable.html
At some point in your career (probably rather early in it, to be honest!), you will have to dig into code written by someone else to either enhance or fix it. In some circles, this is one of the most dreaded tasks, but it doesn’t have to be. Learn how to take a strategic approach to grokking a foreign code base. And for a wonderful example of applying the principles, check out this article.
http://thefullstack.xyz/dealing-with-someone-elses-misery-happiness/
Almost undoubtedly you have worked on a project (or a few!) that had schedule problems. This article discusses the idea that poor project management and communication practices are at the root of poor estimation. The author goes on to provide a detailed example of how even simple requirements have hidden factors that are often overlooked in estimation and offers some good ideas for developing the proper mind-set for making good estimates.
https://blogs.dropbox.com/tech/2015/10/what-do-you-mean-you-need-more-time/
Project effort and duration estimation is probably the single most difficult and error-prone aspect of modern software development. In fact, it’s even given rise to the #NoEstimates movement (which actually is focused on finding better alternatives to estimates, rather than eliminating them). In another vein, this author recognizes that estimates are fact of life in most places and says that rather than avoiding them, we need to do a better job of communicating to our customers about what the estimates mean, especially around the precision of the estimate (think statistical distributions) and the distinction between an estimate and a commitment.
http://apsis.io/blog/2016/04/18/communicating-estimates
You’ve probably heard most of these laws (really aphorisms, but that doesn’t matter!), but this is a unique presentation that groups them together and provides some context for how they apply to programming, especially team dynamics.
http://www.exceptionnotfound.net/fundamental-laws-of-software-development/
Maybe this is just an argument about semantics or something that just doesn’t matter all that much, but it’s still a good discussion about the “workflow” that an application design should go through. Rather than focusing on the definitions of each, the author explains the purpose behind the different phases and how they are used to narrow in on good final design.
http://brainhub.eu/blog/2016/04/20/difference-between-wireframe-mockup-prototype/
While we don’t often hear about them, even physical things are subject to “bugs” due to design. This article shows how the cumulative effect of individual design decisions that in and of themselves are sound and lead to a broken design overall. It’s a very good lesson for developers and application architects to learn from.
http://two-wrongs.com/the-bug-in-the-physical-building
When you need to add a new file or module to your application code base, how do you decide where it should go? In a lot of cases, you probably don’t even think about it, but your choice can be significant. This article discusses four techniques and the advantages and disadvantages of each.
https://medium.com/@msandin/strategies-for-organizing-code-2c9d690b6f33
Seth Godin is one of the most widely followed and respected technology marketing pundits on the Internet and in this essay, he makes a very interesting argument about why, more than anything else, software quality must improve. He uses a salient economic argument, as well as appealing to buyers and consumers of software to demand higher quality and eschew the “good enough” philosophy.
http://sethgodin.typepad.com/seths_blog/2016/04/our-software-must-get-better.html
Certainly, one of the perennial debates in the software testing realm is about the value and/or necessity of automated testing. Of course, there isn’t any “one-size-fits-all” answer in this matter. Instead of making this discussion about controversial questions, instead the author suggests which roles are best suited for human experts and for tools.
https://www.cqse.eu/en/blog/man-vs-tool/
While I generally fall in the skeptic camp when it comes to automated testing, identifying and using valuable tools is always a best practice. This article gives a detailed example of using the open-source JavaScript test tool called CasperJS (think Casper the Friendly Ghost) to do basic form testing for a web application. The simplicity of the tool is what makes it most interesting to me.
http://www.oxagile.com/company/blog/automated-regression-testing-made-easy-with-casperjs/
Just as with programming, estimating how long and how many resources a testing effort will take is no simple task. This overview of the estimation process gives you some widely-used techniques and guidelines for when each is appropriate.
https://www.qasymphony.com/blog/software-testing-estimation-techniques/
Distributed systems are becoming more mainstream, even if you don’t realize it. For example, virtualization and containers like Docker and LXC have become standard in many environments. According to research from nearly 200 distributed-system failures, most faults can be found with an environment of only three nodes.
http://neverworkintheory.org/2014/10/08/simple-testing-can-prevent-most-critical-failures.html
As noted, I’m typically suspicious of test automation’s value. However, I freely admit that this comprehensive article about not just haphazard test automation, but a robust test automation architecture and supporting code is a great example of a well-designed and executed approach. The author explains not only the implementation, but the philosophy behind how they test and where automation is valuable.
https://engineering.riotgames.com/news/automated-testing-league-legends
Most of us are familiar with the Gang of Four Design Patterns recommendation to "favor 'object composition' over 'class inheritance'." But often it’s not clear exactly why composition is preferred. This article uses a simple, relevant example of the benefits of composition, especially in framework scenarios.
http://www.blinkingcaret.com/2016/04/13/composition-superior-inheritance/
Unit testing is at the core of test-driven development (TDD), but if you are new to TDD, it may not be obvious what the scope of a unit test should be. This article discusses the common definitions and then offers a detailed example of how to break down your code for testing.
http://www.blinkingcaret.com/2016/04/27/what-exactly-is-a-unit-in-unit-testing/
We’ve had tutorials about prototypal OOP for JavaScript previously, but this one is one of the most thorough, yet understandable that I’ve seen. The prototype-based paradigm of JavaScript is probably the part that makes the language most difficult, especially for people coming from class-based languages like Java and C++.
http://alistapart.com/article/prototypal-object-oriented-programming-using-javascript
If you’ve been programming for any appreciable amount of time, you are likely familiar with “What Every Computer Scientist Should Know About Floating-Point Arithmetic”, which is a classic paper in the world of computer science. To help you visual many of the concepts about how floating-point numbers are stored and how FP precision is managed and what happens when you run into precision problems, this site provides a nice visualization of how digits are stored and used.
https://www.azabani.com/labs/floatvis/
This excellent tutorial and reference explains several popular machine learning algorithms for clustering data and gives graphical examples of how the data is presented. Likewise, the article gives suggestions about when each of the methods is appropriate to use.
http://haifengl.github.io/smile/index.html#clustering
Many developers don’t have formal training in programming language theory (PLT), which is the mathematical and philosophical underpinnings of programming languages, so this directory of resources oriented toward self-study may help you learn some of the theory and techniques that you missed. Resources included topics such as category theory, type theory, compiler construction and more and reference books, seminal papers and several videos.
https://github.com/steshaw/plt
At some point in your technology career, you will likely come to the cross-roads between management and technical expert. This excellent article suggests that, to foster engagement and growth of senior technical folks, an organization needs to provide a path that allows the individual move the phases of solution implementer, problem-solver, and “finders” who autonomously fix problems before they happen. The author emphasizes that these roles are not necessarily suited to every organization.
https://rkoutnik.com/2016/04/21/implementers-solvers-and-finders.html
We all know about the “coding interview”, but how much can you really learn about a candidates skills from 15 minutes of watching them code a single method? This author suggests giving the candidate a small (2-4 hours) “project” and having them build it over the weekend and then come back in and present the solution. He even goes as far as paying the candidate for the work, based on the estimated time to complete it, whether you hire the person or not.
https://medium.com/swlh/the-one-method-to-eliminate-bad-tech-hires-630d539b2e1d
We’ve discussed imposter syndrome in development in this newsletter before, but this article goes beyond just talking about the issue to offering some practical steps to dealing with it. Personally, I feel like imposter syndrome is a bigger problem among older developers, especially when we look and the younger folks who are “digital natives”.
https://www.laserfiche.com/simplicity/shut-up-imposter-syndrome-i-can-too-program/
Historically, after a certain point in technology careers, you had to move into management or some other area. But, today, many folks choose to continue as technical individual contributors. This developer provides some practical ideas for how sharpen your skills as a mid-life programmer.
https://medium.com/@akosma/being-a-developer-after-40-3c5dd112210c
Of all of the “soft skills” that you’ve probably heard about as being important in programming, you probably haven’t heard of empathy. Nevertheless, this developer makes a very good argument that perhaps it is one of the most important, because it is the key to understanding the needs of the customers of your application.
http://codingwithempathy.com/2016/05/03/empathy-an-essential-skill-in-software-development/
Almost everyone has more email in their Inbox than they know what to do with. This has led to many well-meaning solutions, from the process-oriented (“email bankruptcy” and “inbox zero” among others), to many re-inventions of the email client (Mailbird and others), and the idea that we should do away with email altogether (Twitter, Slack, etc.). This developer says that email itself is not the problem, but rather our psychology toward dealing with it. His argument is that email is the main medium that we use when asking someone to do something and it should be treated as such. He goes on to explain how train yourself to approach email in this manner.
https://glyph.twistedmatrix.com/2016/04/email-isnt-the-problem.html
This simple JavaScript utility enhances the built-in Git diff functionality to show changes between versions as single lines (no more “+” or “-“!), including highlighting of the actual changes within the line. Likewise, you can customize the colors used in the output. (Note: Requires the sed utility, so your mileage may vary on Windows. A Windows version of sed is available in the GnuWin32 and UnxUtils packages.)
https://github.com/stevemao/diff-so-fancy
Sometimes you need more than a static screen shot (but less than a full-blown video!) to explain something to someone. Moreover, many of the static hosting sites, like Imgur, only take image files. With the tiny ScreenToGif utility you define a frame area of the desktop and record the activity to a standard GIF image. Some of the handy features include ability to pause recording, moving the frame, removing frames from recorded image, and including the mouse cursor (or not).
https://screentogif.codeplex.com/
Marathon is free, open-source automated testing tool for Java Swing GUI applications. It allows you to record, edit, and replay GUI tests and it integrates with build systems, such as Jenkins, so you can run your automated tests as part of the build process.
https://marathontesting.com/marathon/
If you ever work on a source code branch for a significant amount of time, you’ve probably faced the problem of remembering exactly what all changes you made. Likewise, it’s important to comment your code, especially when doing maintenance. What if you could kill two birds with one stone? With Commit Comments you can: just prefix your comments with ‘@commit’ and this Git hook script tandem will add those comments to your commit message. After a successful commit, the ‘@commit’ annotation is cleanly removed.
https://github.com/thebearjew/commit-comments
If you enjoyed Arnold Lobel’s award-winning Frog and Toad books as a child (or perhaps, like me, you were enraptured by them by reading them to your children!), then you’ll want to check out this series of short blog postings in the same style as if Frog and Toad are 21st century technology entrepreneurs. They discuss topics like technical debt, project management, and the like. You might even learn a thing or two!
https://medium.com/frog-and-toad-are-cofounders
Interested in machine learning and, particularly, neural networks? Many of the concepts tend to be quite esoteric, but this site lets you play with a simple one by adding/removing stages and manipulating the configuration of the various stages. Quite a fascinating way to see how small changes in input can have significant effects on output.
http://playground.tensorflow.org/
Does it really matter whether Jon Snow is dead or alive (or somewhere in between)? Never mind that, but how about those amazing creatures? In this article, some top biologists look at the likelihood that some of this menagerie could really exist.
http://gizmodo.com/a-scientific-guide-to-the-fantastical-predators-in-game-1699034796
Even if you’ve never heard of it, chances are that you’ve been to (at least, virtually) Null Island. It’s the representational construct for the point in the Atlantic Ocean at 0°N 0°E coordinates. Many GIS and mapping systems default to this location when they encounter an unknown location.
https://blogs.loc.gov/maps/2016/04/the-geographical-oddity-of-null-island/