March 2014 Newsletter
If you stand up and be counted, from time to time you may get yourself knocked down. But remember this: A man flattened by an opponent can get up again. A man flattened by conformity stays down for good. –Thomas J. Watson Jr.
You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new. –Steve Jobs
If we can really understand the problem, the answer will come out of it, because the answer is not separate from the problem. –Jiddu Krishnamurti
Experienced problem solvers know not to give up too quickly. Many of the great advances in computing came under conditions just like this. –Eugene Wallingford
The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology--the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. –H. Abelson and G. Sussman, Structure and Interpretation of Computer Programs
There must always be some who are brighter and some who are stupider. The latter make up for it by being better workers. –Bertolt Brecht
People have a hard time letting go of their suffering. Out of a fear of the unknown, they prefer suffering that is familiar. –Thich Nhat Hanh
Everyone wants to know what the future holds for development, but it’s
always difficult to decide which trends are likely to stick. This list offers some short- to medium-term
predictions about how programming will change in the next several years.
http://www.infoworld.com/d/application-development/12-predictions-the-future-of-programming-235292
Anyone who has been in development of very long knows that actually
writing code is (usually) only a small part of the job. This essay, which is in response to the on-going debate
about open-plan offices, provides some great insights into all of the other
work that goes into creating software.
http://petewarden.com/2014/02/24/writing-code-is-not-most-programmers-primary-task/
In this podcast, the participants discuss what the future of programming
should be. While, of course, they don’t
settle the debate, they offer some interesting insights, such as the fact that
domain fit for languages is still a significant problem.
http://programming.oreilly.com/2014/02/what-should-programming-look-like.html
As much as possible, I try to avoid being a “fan boy” of any particular
programming language (or even of any technology or process, in general). Of course, I have some personal preferences,
but most of those revolve around what I’m trying to accomplish. This very well constructed and detailed
explanation helps you understand that Java is not dead (and probably not dying)
and that just like any language, Java has both benefits and problems.
http://stevewedig.com/2014/02/17/why-and-how-i-write-java/
Personally, I’m a fan of TDD and believe that it improves not only code
quality, but that it ensures accurate implementation. Nevertheless, just like any methodology or
technique, TDD must be used appropriately and adapted to each situation
effectively. This article gives some good
suggestions for how to practice “balanced TDD”.
http://blog.shaunfinglas.co.uk/posts/2014/02/test-driven-developoment-is-a-tool
This very thoughtful (and it’s equally inspired
rebuttal) essay addresses the current popularity of the concept that
“everyone” should learn to program. This
author makes a strong argument for importance of (at least some people) understanding
the underpinnings of programming from science and math, as well as, the
incorporation of professional practice.
http://shkspr.mobi/blog/2014/02/learning-to-code-vs-learning-computer-science/
This author offers an enlightening perspective on one of the pitfalls of
scrum and other agile practices: It
leaves little time (if any) for us to slow down and think deeply about what we
are building and, just as importantly (maybe more!), why. He suggests a philosophical approach that
eschews the common mantra of “product value”.
http://blog.aha.io/index.php/scrum-random-acts-of-software/
One of the oft-referenced sources of statistics about development project
problems (including in this newsletter) is the Standish Group’s Chaos Report. Scott Ambler, who is well-respected in the
industry, challenges both the conclusions and methodology of the report and
provides evidence that lean development methodologies (which his company
provides consulting services for) can frequently deliver successful projects.
http://www.drdobbs.com/architecture-and-design/the-non-existent-software-crisis-debunki/240165910
Famously, almost 30 years ago, Fred
Brooks said that there’s “no
silver bullet” (This article is a must-read for everyone, if you aren’t
familiar with it.) for problems in software
development. Of course, that hasn’t
stopped the search for a better mousetrap.
This great essay explains how methodologies fall short in trying to
enforce traditional engineering processes on an activity that doesn’t conform
to that style of structure.
http://typicalprogrammer.com/why-dont-software-development-methodologies-work/
You may remember the public-service messages a few years ago for wearing seat belts that used the tag line, “You could learn a lot from a dummy.” Well, as software testers, this article shows that we can learn a lot from airplane test pilots. Their experiences should give us ideas about how test applications at their limits, to test beyond “expected” conditions, and more.
http://www.businessweek.com/articles/2014-02-13/how-airbus-is-debugging-the-a350
Test automation is one of those topics that I always struggle with. While I certainly recognize that today’s tools are much better than in previous generations, I still have a sense that it’s really a sort of snake oil. In any case, this article provides some good context on how automation, particularly using Selenium, can provide some quick value without a large investment, which seems to be the main hurdle for me.
http://blog.filipekberg.se/2014/01/30/test-automation-web-applications/
Agile methodologies have permeated almost all aspects of the development process, including testing. Here are four areas where agile approaches are relevant and effective for testing.
http://www.neotys.com/blog/the-future-of-agile-testing/
In this article, the author looks at the difficulty in developing an effective automated testing regime for an application. His premise is that the cost of maintaining resilient tests outweighs the benefits.
http://www.bennorthrop.com/Essays/2014/the-siren-song-of-automated-testing.php
Git is hard (or, at least, it is for me... and others, too!). But it’s also very powerful, which is why so many people use it. Here are some tips to help you be more productive in your day-to-day work with Git.
https://ochronus.com/git-tips-from-the-trenches/
In this newsletter, we often emphasize the importance and value of non-technical (sometimes called “soft”) skills. This book, which is sub-titled Guidance for the Aspiring Software Craftsman, provides excellent advice about how to learn the “trade” of software development, especially by seeking the guidance of an experienced, skilled mentor. Even “old hands” in the development world can learn a thing or two!
http://chimera.labs.oreilly.com/books/1234000001813/index.html
A few years ago, domain-specific languages (DSLs) were all the rage. And, certainly, tools to build your own programming language have improved. But, the fundamental question still remains: Why do you need a new language to accomplish your objectives? And, even if you can successfully implement an effective language, you still have to convince others to adopt it.
http://www.drdobbs.com/architecture-and-design/so-you-want-to-write-your-own-language/240165488
This excellent four-part series on “Uncle Bob” Martin’s SOLID principles by digging down to the nitty-gritty (always wanted to use that term in the newsletter!) of each item. The author uses simple, detailed explanations and many salient examples. Even if you are not familiar with PHP, the exclusive use of PHP’s OOP functionality makes the examples understandable for anyone with an OOP background.
http://code.tutsplus.com/tutorials/solid-part-1-the-single-responsibility-principle--net-36074
http://code.tutsplus.com/tutorials/solid-part-2-the-openclosed-principle--net-36600
http://code.tutsplus.com/tutorials/solid-part-4-the-dependency-inversion-principle--net-36872
Most readers of this newsletter don’t aspire to become great designers. However, that doesn’t mean that we should ignore following good design practices when building our applications. This site provides a month’s worth of daily user experience design lessons that cover the gamut of topics relevant to web design and development.
http://thehipperelement.com/post/75476711614/ux-crash-course-31-fundamentals
This excellent tutorial shows how you can use new lambda expressions to simplify writing custom Comparator functions in Java 8. The traditional method for writing sorting methods is demonstrated along with the Java 8 approach to help you get a solid understanding of the new lambda expression functionality.
http://blog.jooq.org/2014/01/31/java-8-friday-goodies-lambdas-and-sorting/
For many of us (me included!), jQuery is JavaScript. But to truly understand and leverage the power of jQuery, you really need to understand what it’s doing under the covers. This great tutorial using the jQuery paradigm to build a simple DOM manipulation library with native JavaScript. Along the way, you’ll learn some great tips about doing OOP in JavaScript.
http://cedricruiz.me/blog/building-a-jquery-like-library/
Chesterton (one of my favorite authors!) famously quipped, “It isn't that they can't see the solution. It's that they can't see the problem.” And he’s absolutely right. You can’t solve any problem until you properly understand it. And asking good questions is the best way to determine what problem you need to solve. This article offers many great and practical suggestions for problem-solving through questions.
https://docs.google.com/viewer?url=http://dhemery.com/pdf/questions_to_explore_problems.pdf
Based on data from 2013 from over 100000 coding tests, this site says that Python is the most popular language for the third straight year. Venerable C++ even saw growth while Java popularity declined and PHP dropped precipitously.
This developer offers a very interesting view of the importance in having balance in your work and personal life as a programmer. In particular, he discusses the appropriate attitude that we should have toward our skills and profession (trade?).
http://devblog.avdi.org/2014/01/31/the-moderately-enthusiastic-programmer/
How often have you gotten an e-mail or phone call about a “critical” problem and immediately jumped into trying to solve it only to find out that someone else (or maybe many others!) are looking at it too? This author explains, in the context of being a technical leader, the importance and value of simply waiting a little while and having some patience to allow others to look into the problem first and then use their findings to guide them to the solution.
http://robertgreiner.com/2014/02/wait/
According to a survey of over 2000 workers worldwide, multitasking is one of the biggest productivity drains in today’s workplace. It increases error rates by up to 50%, causes cognitive impairment similar to smoking dope, and may have a global economic impact of nearly $450 billion annually. Thus, we need to learn “coping” skills to the increasing demands for our attention.
http://blog.fuzebox.com/the-high-cost-of-multitasking-infographic/
We all have times when we just don’t feel like doing our work. It’s part of being human. But just because we don’t want to work doesn’t mean that the work stops. This excellent article gives some practical suggestions for how to get going when you lack motivation, based on three of the common reasons for procrastinating.
http://blogs.hbr.org/2014/02/how-to-make-yourself-work-when-you-just-dont-want-to/
At one time or another you’ll have a CSV file that you want to query. Rather than going to the trouble of importing it into your enterprise database, just reach for TextQL. It’s a simple Go-based wrapper for SQLite console shell which allows you to operate on the native CSV (or other structured text format file) using regular SQL syntax. You can even save the output of your session to a SQLite database for use later.
https://github.com/dinedal/textql
Everyone can use a little help at times to make their writing pack a punch. Hemingway is an online text analyzer that provide metrics on your writing, including approximate grade level, as well is inline hints about improvements such as removing passive voice and simplifying language.
While this tool requires some additional configuration (Tomcat, Solr, and MySQL or PostgreSQL), once you’ve got it going, it’s a gem that allows you to search and read Stack Overflow content directly in Eclipse. You can even add references to Stack Overflow articles directly in your source code.
Shortcut keys are great for improved productivity. While Chrome has plenty of built-in shortcut keys, this simple tool allows you to customize and add keyboard shortcuts for such items as scrolling up/down by a little or lot, scroll to the top or bottom of page, switching tabs, zooming in/out on a page, and many more.
https://chrome.google.com/webstore/detail/shortkeys/logpjaacgmcbpdkdchjiaagddngobkck
If you do any sort of development or testing work, you probably frequently have to kill processes on your system. Most people rely on the Processes tab of Windows Task Manager, but Process Liquidator makes the process (no pun intended!) much simpler. It runs in the background and you just move the mouse cursor to the right edge of the screen to display the list of running processes. Then just right-click on the desired process to terminate it. By default, it will prompt you to terminate the selected process, but you can set it to immediately terminate it. Process Liquidator is completely portable.
http://12bytes.org/software/process-liquidator
Wow! A guy watches every episode of Law & Order and documents how the use of computers and technology changed over the 20+ years. It might sound lame, but it’s actually rather fascinating.