If we had a keen vision and feeling of all ordinary human life, it would be like hearing the grass grow. We should die of the roar that lies on the other side of the silence. –George Eliot, Middlemarch (1872)
You have to take risks. We will only understand the miracle of life fully when we allow the unexpected to happen. –Paulo Coelho
It's
hard to explain to a fresh computer-science graduate why you need
conventions and engineering discipline. When I was an undergraduate,
the largest program I wrote was about 500 lines of executable code.
As a professional, I've written dozens of utilities that have been
smaller than 500 lines, but the average main-project size has been
5,000 to 25,000 lines, and I've participated in projects with over
500,000 lines of code. This type of effort requires not the same
skills on a larger scale, but a new set of skills altogether. –Steve
McConnell, Code
Complete
Nowadays people know the price of everything and the value of nothing. –Oscar Wilde, The Picture of Dorian Gray (1890)
Any fool can criticize, condemn, and complain, but it takes character and self-control to be understanding and forgiving. –Dale Carnegie
Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. –Charles M Strauss
You are not big enough to accuse the whole age effectively, but let us say you are in dissent. You are in no position to issue commands, but you can speak words of hope. Shall this be the substance of your message? Be human in this most inhuman of ages; guard the image of man for it is the image of God. –Thomas Merton
Using an observation of John D. Cook, this author extends the concept of code complexity thresholds (based on number of lines of code) at which developers of various experience levels reach significant impediments. He says that ~2000 LOCs is the limit for novice programmers to be able to work with code and ~20000 LOCs (an order of magnitude increase) is most that experienced developers can maintain. While these are certainly anecdotal references, it’s an interesting idea to consider when trying to effectively manage your code base.
http://www.teamten.com/lawrence/writings/norris-numbers.html
While I’m personally skeptical about ever being able to completely stop doing work estimation, this article reviews a couple of experiments in comparing relative story point estimates to actual with various results and in comparing the sum of iteration velocity to count of stories completed. The second metric turned out to be a good predictor and would allow a team to simply estimate the number of stories that they could do as a proxy for other estimation.
http://winnipegagilist.blogspot.com/2015/05/journeying-towards-noestimates.html
Let’s cut straight to the heart of the matter on this one. The author says that the key to good application development is: data first, not code first. In other words, define your data entities and data structures at the beginning and then develop your objects and methods around them. This tracks very closely to Linus Torvalds’ comment: … [T]he difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
http://etodd.io/2015/09/28/one-weird-trick-better-code/
This article gives an interesting perspective on agile methodologies and the apparent paradox that, in particular, the scrum approach is almost universally loved by managers and loathed by developers. The author claims that main drawback of scrum methodology is that it involves a trade-off between predictability and speed in favor of the latter. Moreover, he suggests that Kanban offers a better compromise for this problem.
http://coderlifestyle.com/agile-development-scrum-kanban-and-the-observer-effect/
In most organizations, even tacit acceptance of shadow IT (sometimes called “black ops” IT) is considered heresy by IT insiders. This author says that IT needs to develop a collaborative relationship with business-led IT work as part of its overall effort to make the organization successful.
http://techcrunch.com/2015/09/25/its-time-to-embrace-not-fear-shadow-it/
Most of us are familiar with the concept that slow performance of web applications causes users to abandon your site. But what is it that underlies users leaving your site? This excellent article discusses the psychology of time perception and how it relates to web applications, including considerations for web design.
http://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/
We’ve all heard the advice to prefer composition over inheritance in object-oriented programming. But what is the reason for this maxim? This video, with transcript, explains the concept in a very understandable way with several examples using JavaScript.
https://medium.com/humans-create-software/composition-over-inheritance-cb6f88070205
Unit testing. Every developer knows that it’s the right thing to do. But sometimes getting started can be difficult. This excellent tutorial explains the principles and process by considering a handful of questions that you should ask to do test-driven development. Hey, self-talk is good, right?!
https://medium.com/javascript-scene/what-every-unit-test-needs-f6cd34d9836d
Sometimes, when we are fixing a really difficult problem in code, we are so relieved to have it fixed that we skimp on explaining the cause and solution. This article provides a good example of the value, not just to you, but to your team, of providing the details behind the problem and how you fixed it.
http://rentes.github.io/programming/stackoverflow/2015/09/03/Wisdom-of-the-Ancients/
This interview-style article addresses some of the common misconceptions about what testers do, especially those in the game industry. The author emphasizes that testing requires strong technical and communication skills.
http://blog.goyello.com/2015/07/02/want-to-be-a-tester/
One of the age-old questions in software testing is: How do you know when you are “done”? In this essay, the author suggests that defining a bug-detection rate threshold (i.e., number of bugs per hour of testing) beforehand is a good way to (more or less) objectively determine when testing should end.
http://www.yegor256.com/2015/09/10/testing-exit-criteria.html
This article discusses that at the same time as the profile and importance of software testers to the success of projects increases, the role is also changing. One of the key points is that testers often act more in a facilitator role than as a strictly technical person on the team.
http://sdtimes.com/software-testing-no-longer-stands-alone/
After more than 100 years of fine tuning, most of the mechanical problems with motor vehicles have been systematically addressed. The new frontier for auto problems is the plethora of software that manage all of the various systems. And with recent demonstrations, such as remotely disabling a vehicle over the Internet, software quality and security are a top priority for automakers. And they are rising up to the challenge, if slowly.
When starting out in software testing, most of us think that our job is to uncover each and every defect lurking in the code. As we mature, we soon learn that the main role for testers is risk management and mitigation. This article gives you a handful of practical ideas for how testers can support their teams by identifying and lessening risks.
http://www.stickyminds.com/article/5-ways-testers-can-mitigate-practical-risks-agile-team
You may think that this topic is passé, but it’s a worthwhile read. Even though RDBMSs are quite well understood, you’ll probably pick up a tip or two that will help you design your databases more efficiently or index them appropriately.
http://coding-geek.com/how-databases-work/
In agile practice, user stories tend to be the center of gravity for the project team. Therefore, it makes sense to ensure that your stories are the best possible. This comprehensive guide provides some best practices for writing and maintaining stories, including several factors that are often overlooked.
http://techbeacon.com/essential-guide-user-story-creation-agile-leaders
JavaScript has quickly become the lingua franca of the development world, due to its ubiquity. If you are new to it and coming from a more traditional programming background (Java, C++, etc.), some of the JavaScript quirks can be confusing. This article gives you the key concepts that will help you quickly make the transition.
http://developer.telerik.com/featured/pro-javascript-concepts-for-enterprise-developers/
While the author of this article considers some of these practices to be excessive, they all seem to be good habits to use to write good quality code. You probably already use some of these, but you’ll likely pick up a few good tips, as well.
http://blog.jooq.org/2015/08/11/top-10-useful-yet-paranoid-java-programming-techniques/
While the CQRS (Command Query Responsibility Segregation) architecture pattern has been around for a while, it has recently started to gain more popularity with the advent of distributed systems and microservices. This comprehensive tutorial explains the principles and how to use it in practice in the context of domain-driven design.
Not too long ago, a lot of pundits claimed that NoSQL meant the imminent demise of RDBMS platforms based on SQL. Well, not surprisingly, that didn’t happen and, today, it seems clear that both SQL and NoSQL have places at the table. This balanced review compares and contrasts them generally and gives advice about when each are appropriate to use.
http://www.sitepoint.com/sql-vs-nosql-differences/
Certainly, we’ve all worked with our share of negative people. Perhaps you are one of them (like I used to be!). But which mindset, positive or negative, is better at work? This article notes that cynicism has the distinct effects of lower income and impeding collaboration.
http://adigaskell.org/2015/06/15/does-it-pay-to-be-cynical-or-optimistic-at-work/
The fallout from the NY Times article about the work culture at Amazon continues. This article discusses the significant body of research that shows that consistent overwork is damaging not only to workers, but also their organizations, as well. The indication is that a culture of overwork is simply a proxy for other organizational problems.
https://hbr.org/2015/08/the-research-is-clear-long-hours-backfire-for-people-and-for-companies
An interview (kind of meta, huh?!) with the lead developer at LivingSocial discusses some of the problems with technical interviewing and then offers some suggestions on how to streamline the process and improve the results of hiring.
One of the leadership buzzwords of the past several years is ‘empowerment’. In this article, the author turns the concept on its head by pointing out that, in many cases, management needs to stop “dis-empowering” employees instead of practicing a disingenuous effort of empowerment.
http://allankelly.blogspot.com/2015/09/stop-empowering-people-end.html
Social scientist Barry Schwartz, who gave us The Paradox of Choice, considers the meaning of work and the sociological and psychologic aspects of it in this excerpt from his new book, Why We Work. He discusses the cultural aspects of work and presents some suggestions for how to find happiness in any kind of work.
http://www.nytimes.com/2015/08/30/opinion/sunday/rethinking-work.html
In some ways, HTTPLang is a bit of a curiosity, but it’s still a handy little tool to have, especially for ad hoc testing and troubleshooting. You are probably familiar with cURL and it’s a great tool, but sometimes it’s overkill. To do some simple HTTP scripting HTTPLang might be just the alternative. It allows you to write simple scripts, including loops and conditionals, to interact with HTTP hosts and display the output.
https://github.com/Max00355/HTTPLang
Perhaps the day-to-day use of this tool is questionable, but it is a rather unique one. Paste in your JavaScript code and it will generate an abstract syntax tree (AST) of the code using one of the common JavaScript parsers, including Esprima, Acorn, and Babylon. The AST can be displayed as a tree or in JSON format. It’s a very useful tool for understanding how your code is structured when executed.
Most Java developers are familiar with JDBC and JPA as well as the variety of popular ORMs, such as MyBatis and Hiberate, for data access in Java applications. However, sometimes you don’t need all of the bells and whistles (and complexity!) of these tools. JDBI provides database access using a fluent interface with parameter binding and automatically uses the native Java collections API to store results. Check out this tutorial to learn more.
Sift is a cross-platform (developed in Go language) alternative to the venerable grep utility with a focus on performance. For each platform supported, it comes as a single file and it’s performances tends to be 1-2 orders of magnitude better than grep and other similar text search tools.
In Windows Explorer, if you want to open a Command Prompt in the folder currently displayed, just enter cmd in the Address bar and press <Enter>.
This brief list is only partly tongue-in-cheek. A couple of these sound like they would actually be useful, especially with respect to learning the tricks to developing software with good performance. Maybe there is a bright future for software archeology.
http://prog21.dadgum.com/210.html
Doubtless you studied (and, perhaps, even had to memorize) Robert Frost’s most famous poem, “The Road Not Taken”. But did you really learn it? In this excerpt from a new book examining the poem and what it tells us about America, the author says that it occupies a distinct position between understanding and meaning. Quite philosophical, but perhaps not!
http://www.theparisreview.org/blog/2015/09/11/the-most-misread-poem-in-america/
What if the Internet had a page that was a mile long? Well, now it does! This site, if scrolled is a mile long. Along the way, it tells you some interesting facts about things are the length that you are currently on.
Instead of scrolling in your browser for a mile, maybe you’re more interested in comparing the relative size of geographic areas. Check out this site where you’ll learn some interesting facts about geography by doing visual comparison.
So, you probably know about cowsay, right? But who doesn’t want to get a little bit of pithy programming wisdom from a manatee? Too bad it’s not Barbara Manatee, but that’s probably because she doesn’t speak French!
Certainly, you are familiar with buzzword bingo. Well, here’s an interesting twist on the concept specific to words or phrases that you are likely to here in your daily standup for scrum.