The hardest bugs are those where your mental model of the situation is just wrong, so you can’t see the problem at all. –Brian Kernighan
What’s the worst thing I’ve stolen? Probably little pieces of other people’s lives. Where I’ve either wasted their time or hurt them in some way. That’s the worst thing you can steal, the time of other people. You just can’t get that back. –Chester Bennington
Vim also fails, largely because it is very difficult for beginners to use. Most people can sit down with Sublime Text or Emacs and just start typing. In Vim, you have to learn how to enter Insert mode before you can even type! I also think that Vimscript is a large negative, it can make it annoying to expand the editor's abilities. Rather than just casting Enchant Item, you have to sacrifice a goat in a satanic circle to enchant it. –Hunter Praska, "Making Good Tools"
Watch your thoughts, they become words; watch your words, they become actions; watch your actions, they become habits; watch your habits, they become character; watch your character, for it becomes your destiny. –Frank Outlaw, grocery store magnate (maybe)
On most projects, the second most important factor (after cost, of course!) to the customer is when they can have finished product. However, software development is not like other project-based work and estimation is notoriously difficult. What would you say is the most challenging aspect of overall estimation? According to this author, delays for various reasons, and most often for unanticipated factors, are the major cause of poor estimates.
https://levelup.gitconnected.com/why-software-development-estimations-are-hard-f477ceb42a45
If, as noted in the article above, estimation is so difficult and rarely results in accurate estimates, shouldn't we just abandon it? This author, who is the creator of the Django web framework, says that estimation still has great intrinsic value, especially in terms of effectively breaking down the work to be done and understanding what is required. The author also links to another article with some great ideas for learning and honing your skills in making better estimates.
https://jacobian.org/2021/may/20/estimation/
While I recognize that new tools come along all the time that change the way organizations develop applications, I find it very hard to believe that within a couple of years the vast majority of development will happen by business users via low-code tools. I'm not opposed to such tools, but integration alone is such a complex part of application development that, without proper architecture and orchestration, organizations will lose much of the benefit gained from these tools. What do you think?
Using the oft-repeated mantra of "follow the money" as a starting point, this author explores how the financial structure of an organization influences IT transformation efforts. He looks at how many IT organizations focus on "culture", but these efforts are often ineffective due to the constraints placed by finance. A very interesting and thought-provoking article.
https://zwischenzugs.com/2021/07/12/if-you-want-to-transform-it-start-with-finance/
Agile methodologies are going through some struggles right now, mostly around the commercialization of what was intended to be a grassroots approach to improving time-to-delivery of applications. Nevertheless, the underlying principles are generally sound, both philosophically and methodologically. This article provides the bare essentials to get started with agile in an organic fashion.
https://paul.copplest.one/blog/agile.html
We often spend a lot of time and effort on estimation of development work and tasks, but how do we know that we're working on the most important things? This is where prioritization comes in. This article gives a broad perspective on prioritizing, including some of the techniques you might use.
https://kevlinhenney.medium.com/changing-your-priorities-19202e42546e
We often hear about the importance of having the testing team involved the development process as early as possible in a project, even during during the requirements-gathering and design phase. But why is that important? As this article discusses, at each step in the development process it gets exponentially most costly, both in time and economically, to correct problems, so the earlier they are detected, the lower the cost.
https://dzone.com/articles/the-exponential-cost-of-fixing-bugs
In this broad-ranging article, the author explains very well why following good practices that produce quality code result in quicker implementation, even thought it seems counterintuitive. He emphasizes that the new "low-code" and "no-code" tools that are making their debuts are likely providing false hope to organizations, because their marketing fails to account for many of the process factors required to build high-quality applications and systems.
James Bach looks back at how he “discovered” testing early in his career more than 30 years ago. He emphasizes the practical focus of testing on providing value to the customer in terms of reporting the status of the project with respect to readiness, risk, and fitness for use, rather than as ticking off whether test cases pass. Finally, he notes that testing is a human endeavor which requires strong critical thinking skills developed through practice.
https://www.tricentis.com/blog/desperately-seeking-testing/
Of course, there is no single set of absolute best practices for Git (or anything for that matter!), but even though this list is rather old (from 2013), it contains some excellent guidelines and principles. It goes far beyond the simple "mechanics" of git clone, git commit, git push, etc. and focuses instead on the process of using Git in the larger development ecosystem and how to become productive with it.
https://sethrobertson.github.io/GitBestPractices/
You probably already use the Unix/Linux tail command to watch log files when troubleshooting problems or debugging server-side code. This article provides some great suggestions for simple, yet powerful, uses of tail that can supercharge your work.
https://blog.robertelder.org/intro-to-tail-command/
At some time or another in your development career, you will inherit a code base with some very large functions and you’ll need (or want!) to refactor them for better modularity, understanding, etc. This comprehensive guide, using C++ as an example, but easily adapted to most any imperative language, gives practical tips on breaking the monolith down into suitable chunks.
https://robert.muth.org/refactoring-large-functions.html
Many times, software testers confuse their role as finding defects, rather than quantifying and minimizing risk to a project. This excellent reference examines software development risks from a variety of dimensions to help you improve your skills in targeting testing in the appropriate areas of your project.
https://github.com/risk-first/website/wiki/Risk-Landscape
Most programmers and testers have at least heard about functional programming, but what is the core principle behind this paradigm? This author posits that the declarative style is the cornerstone of the functional paradigm based on the concept of each function/method having clear boundaries that avoid changing global state.
https://pragmaticreview.com/the-idea-behind-functional-programming/
Certainly, tech worker ranks have more introverts than extroverts. However, we also have a myth that introverts don’t make good leaders and managers. Perhaps a good part of the problem stems from poor definitions; where you are on the introversion-extroversion scale simply has to do with whether you get energy from alone time or being with other people, not the false premise that introverts are “antisocial”. This article explores some of the distinct benefits that introverts bring to leadership roles.
https://thehustle.co/why-introverts-make-great-leaders/
It’s probably obvious that longer you’ve been in a job, the more intrinsic value you have to your organization (generally speaking, of course). So that should translate into better compensation, right? Of course, the answer is “complicated” and perhaps a bit less than satisfying. Nevertheless, this article will give a good sense of some of the factors involved and, if nothing else, it has a nice visualization to consider when deciding whether to take a new position.
https://marker.medium.com/why-dont-tech-companies-pay-their-engineers-to-stay-b9c7e4b751e9
Based on a self-selected survey of over 80,000 developers in May 2021, learn about their preferred languages and tools, some demographic summary information, and more. A couple of interesting details from the report: more than half of respondents have been developing professionally for under 10 years and almost 2/3 work in small- or medium-size businesses (under 500 employees) with nearly half in companies of 100 or less.
https://insights.stackoverflow.com/survey/2021
Sure, the article title sounds like pure click-bait, but since it’s from The Economist, it’s chock full of great advice. What can classic literature teach us about how to run meetings? Perhaps you’re skeptical, but assuredly “modern” management hasn’t fared well on this subject. Interestingly, several classics actually begin with meetings, so they can be trusted for guidance. Here’s one tidbit from a personal favorite, Golding’s Lord of the Flies: Meetings beget meetings, not results.
https://www.economist.com/1843/2021/08/03/why-satan-should-chair-your-meetings
Diversity and inclusion in technology jobs is one of the most important issues facing our industry, just as it is in our society as a whole. One area that often gets overlooked is "ageism" and particularly the long-standing idea that older workers aren't suited for front-line programming work. This article examines this both in general and through some specific cases of older workers thriving in development well past 40 years of age.
https://thenewstack.io/challenging-the-myth-that-programming-careers-end-at-40/
You're probably thinking that this article title is either click-bait or utter confusion, but it's neither. The author genuinely examines how the Amish approach to technology adoption can help each of us make better choices. Specifically, he says that we should eschew jumping at each and every new technology and take a slow, cautious, deliberative, yet open-minded approach to them. Moreover, he suggests considering the long-term effects, including the cultural and societal impacts.
https://psyche.co/ideas/to-be-more-tech-savvy-borrow-these-strategies-from-the-amish
Crystal is a cross-platform language with syntax strongly inspired by Ruby with many enhancements. Some of the differences include channel-based concurrency like Golang, static type-checking at compile time, null reference checking, and macro-based metaprogramming features. It uses the LLVM infrastructure for compilation resulting in high-performance code. Likewise, after more than 10 years of development, the language recently celebrated it 1.0 release.
pet is a simple, yet powerful command-line code snippet manager for Windows, Linux, and MacOS X. Its best feature is the ability to parameterize the snippets and run them directly from the tool with pet prompting you for each parameter. Saving new snippets is easy: just enter the snippet and description. That's it! You can search on both the descriptions and the snippet contents.
https://github.com/knqyf263/pet
MacType is a tiny and fast font-renderer for newer versions of Windows that vastly improves the look of typography on the screen. It works transparently with most applications, but be sure to check the wiki for details if you run into any problems.
https://github.com/snowie2000/mactype
Web Search Navigator is a handy extension for Firefox and Google Chrome that adds keyboard shortcuts for several popular web sites, including Google, Amazon, GitHub, and YouTube. All shortcuts are fully configurable.
https://github.com/infokiller/web-search-navigator
HTML Notepad is a small notepad that uses standard HTML markup instead of other formats such as Markdown. While not intended to be an HTML editor, it’s suitable for small HTML documents. One of it’s hallmark features is showing the document structure/hierarchy in the margin. The small binary size is achieved through use of the Sciter SDK, which is an alternative to Electron, and HTML Notepad is one of the built-in examples for the SDK.
ts-node provides a complete TypeScript run-time environment and REPL to help you with TypeScript development. You can write shell scripts natively in TypeScript in much the same way as you would do with any other language using standard shebang syntax. Likewise, the REPL allows you to do interactive development and run commands immediately.
https://github.com/TypeStrong/ts-node
This simple command-line tool built with Python lets you run SQL-like queries against CSV and any tabular text format data. You can even query the output from shell commands directly without saving the data to a file first. It supports SQL features like joins and aggregation (GROUP BY) along with many built-in functions. It's very handy for quick, ad hoc queries of data.
If you use the Linux command line often, one of the greatest features is the history of commands run. Simply press the up and down arrows to navigate backward and forward through the commands or hit <Ctrl>+R to search. However, if you navigate around a lot and list directory contents, your history can filled with extra commands that you aren't likely to want to from history, since they are simple enough to just run again. To prevent history from adding these to your command history, just add the HISTIGNORE variable to your .bashrc with a list of the commands to ignore separated with colons (:). Here's an example:
HISTIGNORE="ls:ls -lrt:[bf]g:history*:exit:*shutdown*:*reboot*:[ \t]*"
In this example, we ignore ls by itself and ls -lrt, the bg and fg commands, exit, and anything starting with history. Likewise, you can see that we've included "dangerous" commands like shutdown and reboot that we probably don't want to accidentally run when quickly scrolling through a long history list. And, finally, [ \t]* means to ignore any command that you enter that starts with a <Space> or <Tab> so that you can selectively run a command and have it ignored in the history.
The Linux ls command is limited to displaying the symbolic format permissions for files and directories. However, Linux has the little-known, but powerful stat command that allows us to display a simple directory listing that shows both the text and octal (e.g., 755) formats. At the command prompt, in your desired directory, run:
stat -c "%A %a %s %n" * | column -t
The %A and %a format specifies display the text and octal permissions, respectively; %s and %n display the size and name. And | column -t simply gives a nice tabular format to the output. If you find yourself using this frequently, you can add this as an alias (without the | column -t, unfortunately, but you can still add it to the command line when you run it!) to your .bashrc. I like the name perms, for "permissions":
alias perms='stat -c "%A %a %s %n"'
With the ultra-wealthy it's rather difficulty to get context of just how much money they actually have. This site lets you pretend to spend Elon Musk's estimated $164 billion fortune on various items from video games to sports cars to sports teams! With that much money, it's not as easy as it sounds.
https://spend-elon-fortune.netlify.app/
Recently, many tools and functions have been "gamified" to promote their adoption. So why not gamify the venerable cd shell command? With this little command-line utility, all of your directory change operations become an RPG filed with monsters and adventure. Gear up and slay creatures in every directory!
https://github.com/facundoolano/rpg-cli