Posts in Programming

BASIC is the First Programming Language to Receive a Historical Marker

June 18, 2019 Posted by Programming 0 thoughts on “BASIC is the First Programming Language to Receive a Historical Marker”

The BASIC programming language is often considered as the language of the 80’s. That’s because the idea of the personalized computer started gaining momentum during that era, introducing a wave of the uninitiated to the world of GOTO. We’ve already shared an article about how magazines used to post BASIC code for enthusiasts to translate into working code. To memorialize the language that taught thousands how to program, New Hampshire Department of Transportation installed the first ever highway marker commemorating a programming language.

However much a footnote this news appears to be, one cannot discount the monumental impact that Dartmouth Professors John Kemeny and Thomas Kurtz and a group of graduate students had on computer science. In 1963,  Kemeny and Kurtz not only developed BASIC to make programming more accessible to the average student, they also built a time sharing system that acted as a precursor to the internet.

credit: Dartmouth

The Dartmouth Time Sharing System(DTTS) was built by Kemeny, Kurtz, and graduate students to provide equal access to computing. Two of the key goals of the project was to make the time sharing system free and open-sourced. The program also came packaged with the first Integrated Development Environment(IDE). IDE commands had such a fast response time that many users believed that IDE commands were in fact BASIC commands and that the terminal was the actual computer. In that case, a brand new computer in the 80’s showcasing, 10 Print "Hello World!"20 Goto 10 would have in fact been displaying a terminal.

Where DTTS truly became the prototype of today’s internet was in the formation Kiewet Network. As DTTS spread across several high schools and colleges, users of DTTS were connected via teletypes, modems, and dial-up lines. Both Kemeny and Kurtz stressed the importance of extending beyond the technically-inclined. The idea was to remove the stigma that computers often garnered. BASIC and DTTS allowed 80% of Dartmouth students to become experienced in programming by 1968. That’s because using a computer was synonymous with knowing how to program. The fear that Kemeny and Kurtz really wanted to dispel was the fear of coding. There’s something to be learned about making programming accessible to non-technical students in our era of IT. Now that computers have been enhanced with GUI, there’s been a much less greater emphasis on teaching students how to use computers.

Unbeknownst to the creators of BASIC and DTTS, they had created the concept of personal computers. You can get a sense of this new phenomena in Kemeny’s brochure: “…any student may walk into the Kiewit Computation Center, sit down at a console, and use the time-sharing system. No one will ask if he is solving a serious research problem, doing his homework the easy way, playing a game of football, or writing a letter to his girlfriend.”

David Brooks, contributor to Concord Monitor, spearheaded efforts to have BASIC enshrined in a highway marker. He’d also attempted to get DTTS mentioned along with BASIC, saying, ” Our original idea was to mention both BASIC and the Dartmouth Time-Sharing System…[h]owever, the N.H. Division of Historical Resources, which has decades of experience creating these markers, said it would be too hard to cram both concepts into the limited verbiage of a sign.”

Though Edsger Djikstra may have had a few gripes with BASIC, he cannot deny that the language introduced a flood of people to a world that often seems alien to outsiders.

image credit: TheVerge
Please follow and like us:

JavaScript is the Most Used Programming Language, According to JetBrain Poll

June 14, 2019 Posted by Programming 0 thoughts on “JavaScript is the Most Used Programming Language, According to JetBrain Poll”

To kick off 2019, Jet Brains polled nearly 7,000 developers to determine “the state of the developer ecosystem.”  69% of those surveyed where fully employed while only 15% were students. To put the population into perspective, Stack Overflow’s 2019 survey had a population of 90,000 developers. The larger number allows for a much stronger representation of the developer community. You also have to take the Jet Brains community into consideration. Jet Brains’ most popular product is, arguably, Intellij IDEA, a Java integrated development environment. These variables have to be taken into account when reading the results of Jet Brain’s survey.

With that said, Jet Brains concluded that JavaScript is the most used programming language. HTML/CSS came second while SQL came third. This result came from a question that asked users what programming language they used in the last 12 months. Though the question is awkwardly phrased(it’s possible to use any language for 1 day in a 12 month period), it does show the prominence that front end development has in this current landscape. JavaScript use has become so ubiquitous that there are tools out there that allow you to transpile Java code into JavaScript, a fact that perhaps has led many a developer to rethink their life choices.

Let’s not ignore the fact that HTML is considered a programming language in this poll. Que the endless HTML is not a programming language memes. To be fair, HTML is paired with CSS which, with some(or a lot of) arm twisting, can be considered a programming language due to its turing completeness. Though, in the end it’s really just a style sheet language. Note that Stack Overflow is more careful about this by titling its section Programming, Scripting, and Markup Languages. 

According to the survey, Java is the most popular programming language out there. Here’s where Jet Brains population may have skewed the results. Some may argue that if Java was so popular, there wouldn’t be a need for both Scala and Kotlin.

The survey also found that two-thirds of developers practise pair programming. The problem with this finding in particular is that 1 in 14 developers that took the survey were in some sort of leadership position. A majority of them owned a small business. This is relevant because project leaders would like to assume that they are employing the latest agile methodologies.

Overall, the survey provided some interesting insights into the practices of a select group of developers, but the limited population restricts one from making sweeping generalizations.

Please follow and like us:

9 Linux Tools That Make Programming on Terminals Easier

June 13, 2019 Posted by Programming 0 thoughts on “9 Linux Tools That Make Programming on Terminals Easier”


The Unix philosophy embodies a system of modularity, which allows for a seemingly limitless opportunity for extending various Unix systems. Many tools arise to help programming on Unix systems more bearable when interfacing with a terminal, one of the most important tools for interfacing with a Unix system. Below are tools that make programming on terminals more bearable.


Zsh/ Oh My Zsh

Zsh is the de facto terminal for Unix users. The Unix shell is excellent because of its command line completion, which allows you to write more scripts with fewer keyboard inputs. The community has also created extensions like Oh My Zsh, which make the Zsh easier to install and use for newcomers.


Are you tired of looking at bland ls outputs? lsd, not to be confused with the drug, adds color to output. Colors correspond to different sections of ls output like directories and executable files. The contributors claim that lsd is faster than colorls due to the fact that lsd is built with Rust as opposed to Ruby. At the moment, there are no options to customize the default colors.


Fzf is a general purpose fuzzy finder that can filter files, command history, processes, hostnames, bookmarks, commits, and anything else that is structured in a list. The fuzzy finder boasts super fast search speeds.


Kitty is a terminal emulator that leverages your system’s GPU to improve speed. The emulator is built from the ground up to support modern terminal features like images, unicode, ligatures, tiling and much more.


Bat is a clever renaming of cat, coming packaged with the normal concatenation and printing functions. In addition, Bat adds some nifty features, like text highlighting, git integration, and pagination.


Tmux, like kitty, is a terminal multiplexer that allows you to access multiple terminals on a single screen. This allows you to keep track of multiple programs at once.


jq is a command line JSON processor. The program is a filter that can produce various results. You can use different filters to perform specific tasks and chain these pipes together without the need for loops. jq is written in portable C and comes with no dependencies.


exa attempts to be a modern replacement for the age old ls command. Data is highlighted and file information is extended for easier browsing.


Meld is a visual diff and merge tool that allows you to compare changes in order to avoid merge conflicts. Meld is compatible with a multitude of version control.


Please follow and like us:

8 Websites That Will Make You a Better Problem Solver

June 4, 2019 Posted by Programming 0 thoughts on “8 Websites That Will Make You a Better Problem Solver”

One of the most stressful aspects of looking for a developer job is prepping for technical interviews. Often it’s the problem solving questions that keep candidates up late at night. These problems aren’t geared towards your knowledge of a particular language–the recruiter would expect you to  already have a certain level of expertise in a language. Rather, the technical interview tests your problem solving process. How do you think about a problem? Do you communicate effectively, or do you simply internalize a problem?

Though you generally don’t need to have a strong mathematics background to succeed in coding challenges, it helps to know the basics. For example, it would be helpful to know what prime numbers are if you’re asked to list a series of prime numbers in a challenge. is a great review site that presents a simplified overview of concepts.

Below, we’ve listed sites that provide challenges that will help you sharpen your problem solving skills. But to build good habits, you should practice communicating your thoughts out loud, as if someone were in the room with you.


Project Euler

If you’re not looking for the bells and whistles of community based code challenge sites, then Project Euler is the best website to find a range of challenges. There are 663 problems on the site for you to bang your brain against. Many of these problems are fair game in a technical interview.



Kattis positions itself as a platform for companies, schools, and problem solvers. Problem-solvers specifically get to select from a list of alphabetically ordered problems. The website also offers a leaderboard of its top 100 users. Like many other code competition sites, the top coders can then attract employers.


Codility for Programmers

Codility for Programmers is an extension to the technical recruitment platform. The real value of this website is their lesson plan, which walks you through challenges based on topics like sorting, time complexity, and search algorithms.  Every once in a while, Codility also offers challenges that can earn you a “Codility award.” The submissions are tested for correctness and performance. Awards of silver and gold are given to the runner up and top solution respectively.


Hacker Rank

Hacker Rank is the grand daddy of code challenge websites. If you have the misfortune of stumbling upon the website’s front page, it can be hard to notice that fact due to the way it markets itself as a job matching site. If you make your way to Hacker Rank’s dashboard, however, you’ll find a trove of tutorials that focus on algorithms, data structures, and mathematics. Due to the sites popularity, gaining recognition on the site by participating in competitions can also get you noticed by employers.


Tech Gig

Tech Gig is structured like most other code challenge websites. Though, the barrier to entry for Tech Gig is much more apparent. Hacker Rank requires a login to access challenges and practice problems, but Tech Gig requires a log in from the get-go. The only options for registration are professional and student–and nothing in between. Otherwise, the website offers a nice self evaluation mode that can help inform you about the skills you need to improve upon.


Code Chef

Code Chef is an excellent site for competition due, in large part, to their community. There are usually a few contests to whet your problem-solving appetite and these contests can be hosted by anyone in the Code Chef community. What’s also great is the Stack Overflow-esque question board that sits on the home page, reminding you of the help that the community is willing to offer to its struggling members. There’s also a practice section that groups problems into beginner, easy, medium, and hard.


Leet Code

What makes this website stand out from the rest is that the community offers real world interview questions for you to sink your teeth into. These questions are divided into system design, object-oriented design, operating systems, algorithms, databases, and shell. The practice challenges can be accessed immediately without the need to log in. You can get right to solving challenges that range from easy to hard. Another nice bonus is the built in editor that allows you to do everything in the browser. It must be noted that certain challenges require a premium account to access them, but those premium challenges are few in number.


Code Wars

Of all the problem-solving/challenge sites listed here, Code Wars has the biggest barrier to entry; you have to prove that you know the rudiments of your language of choice before you can proceed. However, the challenge is incredibly easy and functions as more of an inside joke. Once you sign up, you have the option of choosing a skill level ranging from learner to senior developer. There are a bevy of “katas” or challenges to choose from. Challenges are devised by the community. Code Wars provides arguably the best problem solving platform. You have a customizable editor along with pre-written tests that help you get into a real world problem-solving mindset.


Please follow and like us:

What it Means to Code

June 3, 2019 Posted by Programming 0 thoughts on “What it Means to Code”

Coding is often a word that’s thrown around to describe the process of building software, as if the act of typing out characters is what truly makes an app come to life. But coding really isn’t about computers, it’s mostly about people. In terms of the concept of coding(sitting at a desk with your eyes glued to code), we can roughly say that a quarter of coding consists of writing actual lines of code. A blogger conducted an informal study of her internal network among 65 developers and found that they roughly spent 25% of their day actually coding. That percentage may fluctuate day to day, of course, depending on circumstances; e.g. a game developer hitting crunch time.  Still, on average, most of a programmer’s time is spent debugging their own code and the code of other humans, maintaining and rereading code that other humans wrote, and meeting with other humans to talk about building stuff that other humans would enjoy using. And then you have your co-workers that you have to deal with. They have egos, flaws, different perspectives.

You also have coding paradigms and philosophies, which are very human in nature. A developer who has clout within a company can throw his weight around to enforce a particular technology stack that will effect the way you code. The company itself may strongly adopt a functional paradigm which eschews the notion of state-changing behemoths. The computer hardly cares about your company’s decision to use a particular paradigm, but we humans care. We care to such an extent that we’ve created Agile, Lean, DevOps–just to name a few methodologies. All of them influence the way you engage with your code by dictating time spent collaborating with other team members.

Programming languages also embody a certain mindset that centers around how people like to do things. For example, the Ruby philosophy is all about having a variety of ways to solve a single problem. There’s a wild, fast nature to the Ruby on Rails environment that made it popular with boot camp students and startups. On the other hand, Python has a more measured philosophy that tries to enforce “one way to code.” So, it’s not surprising that scientists have created a community around Python. Theoretically, Ruby can easily be used for data science. But since coding is about people and the communities that they form around languages, Python has the tooling that makes it the de facto language for data science.

The problem comes when we forget that coding is not all about computers. That’s what leads to the one line wizardry that looks clever, but takes a page of documentation to explain how the code actually works. It would be nice if the computer could reply back and explain the code to us in plain English. Unfortunately, that’s not the case. A human understanding of code dictates that code should be written for the next person that will either have to review or maintain it. That means providing thorough documentation.

Some people take that to mean every line of code must be accompanied by a paragraph of explanation. Many humans also don’t like reading technical jargon. If every line of code needs explanation, that calls for some refactoring. Crafting elegant solutions should not only be synonymous with the optimal O(logn), but should also be synonymous with high readability.

The human-nature of code extends beyond coders to the people who benefit from the code. Facebook uses algorithms that can suggest articles in your news feed based on  your interests. You can find the nearest fast food restaurant or just stay at home and order some grub. Everyday people use “algorithms” to explain Youtube videos popping in and out of their feeds or Google ads tailoring ads based on the back scratcher he/she bought the other day off Amazon. Code has entered into our dialogue-literally; audio processors have allowed the likes of Alexa and Google Home to become a part of our existence.

Robert C. Martin, author of The Clean Code Blog, details the responsibility programmers now have towards their fellow humans:

It is well past the time that we programmers can safely isolate ourselves from the rest of the world. We programmers must no longer hide in our little techie bubbles. The code we programmers write matters. It matters to the hopes and dreams of our society and of our civilization. It matters to people walking their bicycles across the street. It matters to anyone and everyone because the code we programmers write lubricates, enables, enhances, and simplifies virtually every aspect of daily life. From something as small as a young mother checking her baby monitor, to something as large as international nuclear-weapons policy, and interplanetary travel, our code matters.

Since we code for people, we have to write safe code. Defensive programming ensures that the code you write has minimal bugs. That often means writing clean code so that the bugs themselves can be more easily traced. The code should be nearly fool-poof against extreme cases and weird input.

So, all that said, what does it mean to code? Well, in 2019 coding is about writing for your fellow developers and your customers.



Please follow and like us:

Understanding DevOps

June 3, 2019 Posted by Programming 0 thoughts on “Understanding DevOps”

What is DevOps?

Linguistically, DevOps is a mashup of two departments: development and operations. Functionally, DevOps is an outlined set of procedures, philosophies, and tools  that aim to bring those two departments together to facilitate faster feedback loops. Faster feedback loops between development and operations means that products can be built, tested, and pushed to the public more reliably. The problem many have when they hear the word DevOps is that they think it’s a special ops team akin to the military. Implementing DevOps into a company isn’t a magic bullet since it requires both your developers and, say, IT guys/gals, to adopt certain philosophies that encourage co-operation.

It could be that a company is so well structured that they’re practicing DevOps without formally calling their system DevOps. That’s because the whole concept of DevOps is really a mashup of  agile, lean principles, continuous delivery, automation, and a product-focused mindset.

If you really break down these principles, you’ll understand exactly what “DevOps” values. Oftentimes, in studying development principles you’ll notice an overlapping of buzzwords. Agile is essentially a superset of lean, continuous delivery, and automation. Let’s look at the 12 principles of Agile as stated in the manifesto and examine how closely DevOps adheres to these principles. We’ll even translate some of the principles into “DevOps speak.” In this way, you can really see what DevOps stands for and why it’s not so radically different from all the other methods out there.

Agile and DevOps

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software/ DevOps: Dev and ops teams that work together facilitate this with tightly coupled feedback loops.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project. / DevOps: This is exactly what DevOps proposes, except it adds the Ops people into the mix.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done./ DevOps: Again, DevOps uses this Agile principle to propose the meshing of devs and ops.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation./ DevOps: Dev teams and ops teams shouldn’t be bunkered behind their respective cubicles.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams/ DevOps: This is the crux of DevOps, that collaboration should become a natural phenomenon where product managers, QA teams, design teams, operations, and developers work together on a single product. This creates a product-focused mindset, rather than a functional, dull, assembly-line-like procedure of shifting the burden of responsibility from team to team
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Leaning into automation

As you can see DevOps is congruent with many, if not all, agile principles. Lean principles mostly echo many of the principles outlined above. What I’ll add are some lean principles that address the advantage of DevOps: Built-in quality, knowledge creation, and respect. In terms of quality assurance, a DevOps team optimizes for this with a product-focused mindset that onboards QA. What furthers collaboration, however, is taking on the challenge of quality assurance if you’re a non QA. The principle of built-in quality assures the highest spirit of collaboration since it does not put the burden of one task on a single member.

Shared responsibility requires both knowledge creation and respect. Documentation, code reviews, and training will allow teams to stay on the same page. Proper knowledge creation requires a level of respect for your peers. They cannot be seen as the “Other Team.” That’s the mentality that DevOps seeks to cure by employing lean and agile principles.

These heady principles get funneled into automation. The idea is that teams will be more apt to work together if they can rely on computers to automate the “grunt work.” Another way of viewing this is that working together encourages automation. The buzzword that often comes out of this is continuous delivery(an Agile principle). From a DevOps point of view, continuous delivery is the product of a well-implemented DevOps culture. In a blog post, Martin Fowler described the acid test of continuous delivery.

The key test is that a business sponsor could request that the current development version of the software can be deployed into production at a moment’s notice – and nobody would bat an eyelid, let alone panic.

Then he mentioned what you’d need to achieve continuous delivery: “a close, collaborative working relationship between everyone involved in delivery (often referred to as a DevOpsCulture ). ”


DevOps was born in 2009, when Patrick Debois, a project manager and agile practitioner, created a Devopsdays conference in Ghent, Belgium. “DevOps” entered our lexicon and the rest was history, as the saying goes.  DevOps as an idea, of course, wasn’t created overnight. Whatever ideas have been added over the years have served to solve a single solution: bridging the gap between development and operations.



Please follow and like us:

7 Most Popular Static Site Generators

May 30, 2019 Posted by Programming 0 thoughts on “7 Most Popular Static Site Generators”

In one of our blog posts, we talked about the emergence of the JAMstack as one of the more hyped technologies in 2019. Here’s the definition we gave for the JAMstack:

The JAMstack consists of JavaScript, APIs, and Markup. Nothing remarkable. The stack itself is really a fancy way of promoting the use of static websites. This tech stack is a tech blogger’s response to WordPress. Instead of dealing with unwieldy UI, the tech blogger can simply shift over to GitHub’ simple and familiar version control.

Static site generators are especially useful for coders who love to extend and build but who don’t have the time to do it from scratch. These frameworks offer a solid bedrock of templates and plugins that you can work off to tailor your blog to your liking. At the same time, other site generators offer a more casual approach to non coders as well. Below, we’ve listed the 7 most popular site generators in use today.



Jekyll is one of the more popular site generators for rubyists. In large part due to its close ties with GitHub.  The generator itself is written in Ruby and allows one to start up a blog with a few simple commands. The beauty with the site generator is that due to its affiliation with GitHub, you can host your Jekyll site on GitHub Pages for free. The docs are also easy to follow. Any question about setup is explained thoroughly.



Hugo claims to be one of the fastest static site generators out there with build times clocking at less than a second. Hugo also “supports unlimited content types, taxonomies, menus, dynamic API-driven content, and more, all without plugins.” One of the more interesting aspects of Hugo is its 300+ library of demo-ready themes integrated in the website. As opposed to Jekyll, Hugo is more friendly towards casual developers who simply want a nice looking front end. The docs are solid, though definitely not the best of all the site generators listed here.



Gatsby is the slick, new static site generator for those who love JavaScript and React. Oftentimes, React, due to its take on componentization of the web interface, is often seen as a single-page-app tool. Paired with Gatsby, React is able to be highly effective across multiple pages due to the streamlined routing interface that Gatsby provides. Gatsby also makes use of other modern tech like Webpack and GraphQl.

Due to its heavy reliance on React, the learning curve can be a bit steeper than most other static site generators. Still, the docs serve as a mini tutorial to get you up and running.



The best way to explain Octopress is to qoute the developer of Octopress himself:

“…Octopress is basically some guy’s Jekyll blog you can fork and modify…Octopress is released as a single product, but it’s a collection of plugins and configurations which are hard to disentangle.”

Brandon Mathis would like you to assume that Jekyll and Octopress are practically the same thing. What Octopress boasts is a refined approach to Jekyll blogging. Octopress sets a standard for how themes should look and provides an ecosystem of plugins to enhance the blogging experience. The companion site generator is truly a hacker’s framework.



Hexo is a bare bones static site generator that receives markdown and generates static files. The framework is built atop Node.js, which allows for faster generating speed. The great thing about this framework is its compatibility with Octopress. Most Octopress plugins can be used with Hexo. The easy-to-follow docs speaks to the simplicity of this powerful framework.



Harp’s stand out feature is built-in preprocessing, which automatically preprocesses code before serving it to the browser. Harp’s built-in preprocessors include Markdown, Jade, EJS, LESS, Stylus, Sass, and CoffeeScript.  You can jump straight into CSS because Harp serves that up automatically as well. Harp’s documentation can be improved upon. The videos are unavailable, the outline can be a bit hard to read at times, and troubleshooting info is sparse.



Out of all of the site generators listed here, Pelican doesn’t exactly visually impress. The site uses an extremely bare theme. The site generator itself is geared towards Python users. What truly sets this static site generator apart is its extensive documentation. The organization is impeccable and sets out to answer any question a beginner may have when setting up a static site. If you just want a simple blog presence on the internet, Pelican helps you accomplish your task.


Please follow and like us:

Machine Learning Libraries For Python

May 28, 2019 Posted by Programming 0 thoughts on “Machine Learning Libraries For Python”

Data Science has changed drastically over the last five years alone. Most of that is due to the explosion of libraries that has abstracted much of the “grunt” work that used to take place in the field.  For example, TensorFlow was only released to the public in 2017 and already it’s been used in large scale projects and touted as a library that’s transformed how data scientists go about creating complex neural networks. Including TensorFlow, we’ve listed libraries that have also had an immense impact on the Python/data science community.



Interestingly enough, scikit-learn began its life as David Cournapeau’s Google Summer of Code project. It ended up as one of the more popular libraries for learning algroithms. Built atop NumPy and SciPy, scikit-learn includes vector machines, random forests, gradient boosting, and k-means.



Before Keras, TensorFlow presented the best option for deep learning prototyping and research. It’s arguably still the most popular choice for anyone who wants to manipulate tensors. Actually, with TensorFlow’s integration of Keras, one can also argue that the two libraries are inseparable to some extent. The question is no longer TensorFlow or Keras?  TensorFlow has implemented the Keras API specification into its library with the tf.keras command.

Since machine learning often comes down to using large datasets that are transformed into matrices, TensorFlow provides one of the most flexible options for deep learning research. The library is a powerhouse in the industry and has been used in planet-searching algorithms and for AlphaGo, a competitive AI.



Theano is used to define and evaluate mathematical expressions. The relevancy it has in AI research is that its focus is on not only to evaluate matrix values but  also to optimize them. Theano boasts that its optimization techniques allow one to achieve “speeds rivaling hand-crafted C implementations for problems involving large amounts of data.” It does this by taking advantage of GPUs. Advanced GPUs can even allow one to exceed C implementations “by orders of magnitude.” Due to this, Theano has been used for computationally intensive scientific investigations for over a decade.



Pandas is a high-level  data manipulation library whose focus is on data extraction and preparation. The data structure this language is best known for is the DataFrame. This allows data scientists to list data in rows and columns for observation and variables respectively. Other built in methods allow for searching, combining, and filtering.



One of the best quotes about the usefulness of a library can be found on Matplotlib’s website: “Matplotlib tries to make easy things easy and hard things possible.” Data representation is crucial for gaining insight into learning models. So Matplotlib allows one to generate a bevy of graphs including plots, histograms, power sprectra, error charts, and so on. All of that is possible with a few lines of code…the catch being that the learning curve can be pretty steep due to the size of the library and the age of the documentation.



If you ever get frustrated with Matplotlib, you may want to board Seaborn. Seaborn is a high-level library that extends Matplotlib. The graphs come out looking cleaner on Seaborn and the parameters are easier to work with. Another bonus is that Seaborn was built to be fully compatible with Pandas data structures like DataFrames.



You can think of NumPy as the bedrock of machine learning libraries. Tensorflow, for example, uses NumPy functions to manipulate its Tensors(matrices). NumPy comes equipped with support for matrices and high-level mathematical functions.



Keras presents a user-friendly alternative to TensorFlow. The high level API is commonly used to rapidly prototype either simple or complex neural networks. Keras is especially effective for experimentation purposes, due to the ease of use.



PyTorch is a machine learning library used for natural language processing. The library is developed by Facebook’s AI research team.

Please follow and like us:

What is Technical Debt?

May 28, 2019 Posted by Programming 0 thoughts on “What is Technical Debt?”

Technical debt is an industry buzzword used to describe a design process that, for example, implements code that doesn’t scale. The idea is that by taking shortcuts now to release a product on time, you can deal with maintenance at a later date. That means spending more time on the back end to fix the problems caused by taking a shortcut. One of the more infamous examples of a company taking on technical debt is Oracle. In its nascent years, Oracle was so aggressive in its marketing that it would sell products that it did not have ready. The company’s engineers were forced to rush products into production. Oracle 6 shipped with a ton of bugs. Oracle’s stock plummeted due to this, requiring the engineering team to spend time refining the product.

The effects of technical debt can be damaging to consumer-facing products where customer satisfaction is required to maintain profitability. Yet, one may inquire, why is the term used so liberally if its effects can be so detrimental? The answer is in the cost/benefit analysis that goes into managing technical debt. Ward Cunningham, the man who coined the term, used the analogy of financial debt to illustrate the problems faced by technical personnel. In the financial world, debt can actually be a good thing if one knows how to manage it. The advantages gained by borrowing money for a venture and the potential long term profits outweighs the momentary lapse into debt.

Applied to the technical world, that means writing code with dependencies or tools that allow you to scale a project quickly. For example, a web startup may decide to use Ruby to begin operating immediately with simple rail commands. In this scenario, the debt here is in speed. Ruby and Ruby on Rails is known to be slower than most other languages. When this company starts gaining large amounts of traffic, they will have to address bottlenecks that can only truly be resolved if  they optimize their back end with C++. That means either hiring more developers or training your current developers to work on a back end built with C++.

That’s a solid example for a controlled technical debt. The company used an inexpensive process to gain market share, and then they payed off the debt once the time came to do so.The problem that comes with talking about technical debt is that not all debt is created equally. Oftentimes, as Uncle Bob and Martin Fowler point out, technical debt is confused with hacky code. I remember the first time learning about technical debt.  A coding instructor was casually talking to us about his exploits in the wild. He was hired by a company to build software. Rather than writing code that scales(ie readable code), he just used whatever means were available to him to produce a working product. He called his method technical debt because when his code was audited, there was no way it could go into production without serious refactoring. In the end, he was fired.

Many would argue that that is not technical debt–it’s technical ruin. What my instructor had done was allow an insurmountable amount of cruft to pile up. Fowler defined cruft as, “deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further.”

At what point does technical debt cross the line? Fowler split technical debt into quadrants. You have the deliberate and inadvertent debt. For many of us, inadvertent debt is just part of the learning process. That’s the automatic debt that accrues when you’re working your way through a problem. We may write code that is far too procedural when there’s a faster solution. It’s once we find the solution that we learn how to optimize it. And then you have the reckless debt.

The reckless debt is like the reckless driver–there’s bound to be an accident. Reckless debt means writing clever one line solutions that will befuddle other developers who have the misfortune of maintaining your code. It means writing code without planning and hoping everything turns out alright. It means closing your eyes and hoping you won’t have to deal with a monster of a problem that can potentially tank your project.


image credit:

unsplash-logoAlice Pasqual

Please follow and like us:
pair programming

How to Make Pair Programming Fun

May 20, 2019 Posted by Programming 0 thoughts on “How to Make Pair Programming Fun”

Pair programming is a bit like the buddy cop movies you’ve seen out there. You have two programmers working at the same workstation trying to complete a particular feature or get some tests to pass. Unlike the buddy cop movies, bad pair programming techniques can lead to frustrating scenarios. Whether you’re pairing with a remote developer or someone from the office, there are a few basic guidelines to follow to ensure that the pairing session goes smoothly.


1. Put your heads together(not literally, unless you want to)

If you don’t agree about how to go about completing a task before you start pairing, you’ll only create stress as you code. The best way to introduce your ideas is to first employ some soft skills. Clear the air by talking about anything that may be troubling you so that your fellow programmer doesn’t think that you’re grimacing at his code when you’re really just pissed about something else. The introductions can be as formal or as informal as needed,  just as long as both of you can get on the same page mentally. Once you’ve done that, it will be easier to express ideas.


2. Set up a plan of attack

The productivity parlance “eat that frog” refers to doing your worst(most difficult) task first. When you’re pair programming, you’re probably better off doing the opposite. When I’ve pair programmed, I’ve found that the most exhaustive bit of the task of pair programming was in having to solve  difficult problems. The patience and communication involved in working together can be draining. If this is your first time pair programming together, it will be much better to work on simpler tasks to grow accustomed to working with your pair.

Break down the task into smaller components and proceed from there. However, if you feel that the both of you are pairing rockstars, it may be beneficial to tackle difficult problems early on when you still have the energy to take them on.


3. What’s driving and  navigating?

Aside from deciding what you’re going to be working on, you have to figure out how you’re going to work together. In pair programming, the roles of the pairs are divided into a driving and navigating role. Theoretically, the driver is supposed to be the adventurous road tripper who isn’t really sure about the layout of the land and loves asking for directions. The navigator is supposed to be equally unsure, but the access to information should allow her to help the driver.

Why is this theoretical? Well, depending on the coder, the driver could be someone who starts typing code without communicating. That leaves the navigator with nothing to do but check social media. That’s the worst case scenario of a pair programming session, but it doesn’t have to end up this way if the driving and navigating roles are properly defined.

Some of those new to pair programming may think of the driving role in the way most people think of driving: full control. Your job is to clearly communicate what driving and navigating means to both of you. Should the driver explain what they’re about to write before they write it? Or can they go ahead and write code, then talk about what they wrote afterwards? How much input should the navigator have in writing code? Is the driver mostly a stenographer who receives input from the navigator?

These questions don’t have to be answered. The point is to remind yourselves that the driving role isn’t a one woman/man show. Depending on the nature of the problem, the driver’s role can change. What is most important is that there is constant communication. An effective driver is someone who talks about the problem and possible solution out loud so that the navigator can chime in. A skilled navigator could even optimize a certain solution or refactor the driver’s code on the fly.

The navigator shouldn’t be demanding, however. Suggestions would be received much better if posed in a question. Syntax errors and typos can be pointed out at the last possible moment to give the driver space to breathe. In my pairing sessions, we had fun with typos and syntax errors, turning them into small jokes to lighten up the mood. At the end of the day, the driver may already feels a lot of pressure to write good code in front of their colleague. If the navigator is demanding, the driver’s worst fears may be realized, leading to an unproductive session.


4. Who’s driving and who’s navigating?

Once the roles have been defined, you can then decide how to best split up the task. There really isn’t a bad way to split up tasks. There are formal definitions like ping pong-ing where roles are switched upon completion of a specific task(it’s technically not a drive-navigator style). For example, the driver writes a test for a module and afterwards the roles switch. The new driver tries to make that test pass.

It doesn’t matter how frequently you switch as long as you switch. Switching roles is one of the biggest advantages of pair programming because, in a way, it reduces the pressure of sitting alone for hours hunched over your keyboard trying to solve a problem.

One great way to trigger role switches, if the nature of the task doesn’t provide obvious switch cues, is to set a timer. Every thirty minutes could trigger a switch. Be sure to take breaks in between as well to get some time to yourself.


5. Who gets the credit?

Thanks to git, there’s no need to fight over whose name shows up in the repo. When you create a commit, add aCo-authored-by: name trailer under the commit message. To find out how to do that, check out this GitHub help page.


6. Aftermath

So, you’ve made your last commit for the day. Should you just end the session with a perfunctory good job? While that may seem like the nice thing to do, it really isn’t. If something didn’t go as you expected, it’s better to voice those concerns to allow the pair to fix those problems. The way to introduce those concerns is to first talk about what when well. Then, you can talk about what you can improve on individually or as a pair. Afterwards, you can mention specific issues you may have had with the pair.

If the feedback is given in the spirit of desiring excellence, then it will more than likely be taken in stride. The pair would at least respect you for you honesty even if they may disagree with you.



Hopefully, these steps have given you a blueprint about how to go about pair programming effectively. Pair programming can be a lot of fun if you do it right. You can learn a lot about the person next to you as you hunker down to solve problems. Don’t be surprised if you start sharing a few anecdotes or if a variable name triggers a discussion. Laying down guidelines may seem dull, but once you’ve set up a parameter, you’re free to play knowing that you’re both on the same page. Many site the disadvantages of pair programming, but there’s no doubt that, if done right, pair programming makes staring at code a whole lot more fun.

image credit:
Alvaro Reyes

Please follow and like us: