Posts tagged "programming"

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:

Books That Will Make Programmers Think Outside The Box

May 16, 2019 Posted by Programming 0 thoughts on “Books That Will Make Programmers Think Outside The Box”

Programmers often have to solve a variety of problems that range from something simple like fixing a bug to something more complex like writing a search algorithm for a parking locator app. Different scenarios require different methods of approaching and fixing the problem. That means that a programmer has to have a tool set of mental models to help get them through challenges that arise. For an extremely complex problem, those who are skilled at using first principles won’t be trapped by complexity and will immediately start whittling away the problem into its essential parts. The other parts that are fuzzy can always be researched, or can be handled by someone with more expertise.

Mental models expand beyond a single domain into several other fields; an architect may look at the design of a twisting skyscraper and have one thought while a physicist may look at that same skyscraper and have another thought. Things get even more interesting when you add a biologist into the picture and they notice that the peak of the tower resembles that of a bird’s beak. There are a bevy of problems that had to be solved in creating the skyscraper–someone with the ability to tap into all three of these mental models would be able to come up with unique solutions. The person doesn’t have to be an expert in all of the domains either.

An example of mental models put into practise in an engineering setting are Japan’s bullet trains. For a while, they couldn’t solve the problem of the explosion of noise that would erupt when the trains went in and out of tunnels.  Not until a birdwatcher and engineer called Eiji Nakatsu arrived on the scene with brilliant insight.

He reduced noise by redesigning the rig that connect the train to the wires above to mimic the wing of an owl and redesigned the nose of the train so that it mimicked the nose of a kingfisher. The result was a faster, quieter train.

Let’s look at a programmatic setting. You can combine psychology and systems knowledge to create addictive apps that solve the common problem of, “how do we get users to stay on this app?”  à la Facebook. Psychologists who are well aware of incentives and the feedback loops that engineers can reproduce with their systems knowledge use their own mental models and see Facebook and similar platforms as a source of addiction. Ethics aside, you can argue due to tapping into mental models, Facebook’s programmers have largely solved the retention problem.

There’s no doubt that the application of mental models in real life situations can produce noticeable results. The thing is, knowing how to apply a mental model to a given situation takes a lot of experience. Often, those who solve problems don’t need to say that they used X mental model to solve said problem. Their thought process is intuitive. It takes steps to reach this level of intuition. And the first step is to familiarize yourself with mental models that can help you in your day to day problems. There are tons of books out there that cover a slew of mental models. Sprinkled in this list are books that are more “programmer” oriented. I’ve highlighted the books that cater more to the average programmer.

  • Thinking in Systems: A Primer by Donella Meadow
  • The Fifth Discipline by Peter M. Senge
  • An Introduction to General Systems Thinking by Gerald Weinberg
  • Sources of Power: How people make decisions by Gary Klein
  • Thinking and Deciding by Jonathan Baron
  • Super Thinking by Grabriel Weinberg
  •  The Model Thinker: What You Need to Know to Make Data Work for You by Scott E. Page
  • The Great Mental Models by Shane Parrish
  • How to Solve It: A New Aspect of Mathematical Method by G. Poya
  • The Art and Craft of Problem Solving by Paul Zeitz
  • Object-Oriented Design Heuristics by Paul Zeitz
  • The Decision Book Mikael Krogerus
  • Analysis Patterns by Martin Fowler


image credit:

Susan Yin

Please follow and like us:

8 Programming Languages That Scientists Use

May 10, 2019 Posted by Programming 0 thoughts on “8 Programming Languages That Scientists Use”

There are a lot of general purpose programming languages out in the wild that can theoretically do anything that another language can. For example, Python and Ruby are pretty identical languages. The only reason one has become the dominant language of data science is because of the ecosystem that developed around it. Now, Python is nearly synonymous with data science. But there are other more specific programming languages that cater to a field of science. These are the languages that are considered niche. Those who use them swear by them. To outsiders, you might as well be speaking greek.

Here are eight programming languages(not named Python) that scientists use.



Image result for matlab

credit: Mathworks

Matlab is a programming platform developed by MathWorks to allow for matrix manipulations, plotting data, implementation of algorithms, creation of users interfaces. The language is used mostly by students in university level courses. Matlab comes with an IDE, debugger, and a suite of tools and built-in methods, like most other languages.



Image result for fortran

Though Fortran may seem like a relic today(I posted an article about how it was all the rage in the 80’s), it’s still chiefly used by physicists. The main reason for its continued existence is it’s speed and flexibility when it comes to built-in parallelization and arrays. The language is used along with C++ for high computation tasks that involves modeling stars and galaxies, climate, and electronics.



Image result for ALGOL

This language is a bit ancient and perhaps only in use in certain mainframes–even then its superset ESPOL would be in use. Why ARGOL is relevant now is that it lay the groundwork for languages like Simula, Pascal, C, and Ada. The reason for ARGOL’s influence lay not only in its syntax but its extensive use in academia. Since ARGOL became the lingua franca of algorithmic description, later works would continue to add new ideas to the world of language and algorithm development, one of them being the ALGOL 60 Report edited by Peter Naur. The grammar description later became standardized and was called the Backus-Naur Form.


Image result for apl programming language

The APL programming language is a programming language for the mathematically inclined individual. Like many other programming languages used for mathematical modelling, the multidimensional array is the primary data type of this language. Unlike many other computational languages, APL is hellish to read. The language attempts to abstract complex mathematical functions into representative symbols. In so doing, skilled APL programmers can increase productivity.



Image result for j programming language

credit: iTunes

J is what you get when a developer looks at the crazy symbols in APL and says, “I can fix that.” Instead of relying on foreign symbols, J relies on the tried and true ACII character set. Still, J is notorious for its conciseness. One line of J can do more than one page of code in many other languages.  The language is used for mathematical and statistical programming.



Image result for julia programming language

credit: Wikipedia

Julia has the look of a dynamic scripting language, but it’s multiple dispatch system gives Julia the flexibility to be both dynamic and strongly typed; functional and object-oriented. This means Julia can be applied to various applications. The very ethos of Julia is flexibility. It’s founder, Professor Alan Edelman, wanted Julia to have “the speed of C with the usability of Python, the dynamism of Ruby, the mathematical prowess of MatLab, and the statistical chops of R.” While the language may not have met those loft goals, the principle behind its design makes Julia a handy Swiss Army knife for data scientists.

Wolfram Language

Image result for wolfram language

credit: Wolfram

The Wolfram Language, formerly known as Mathematica, is a language that represents data like strings and integers as symbols. It’s highly symbolic nature is great for representing large data in a clean, readable way.



Image result for r programming language


The R programming language is a language centered around statistical computing. According to the R website, R is “an integrated suite of software facilities for data manipulation, calculation and graphical display.”



image credit:


Lucas Vasques

Please follow and like us:

Best Text Editors and IDEs For Programming In Your Favorite Language

April 30, 2019 Posted by Programming 0 thoughts on “Best Text Editors and IDEs For Programming In Your Favorite Language”

Editors are a fact of life once you coding either becomes a serious a hobby or a full time job. Using the appropriate text editor or IDE can come down to preferences or the specific language you code in. Personally, the three editors I’ve used extensively are notepad++, Sublime, and Atom. I found Notepad++ to be the least readable and customizable. Sublime was an excellent substitute and has a large number of extensions and macros that you can add to make development a breeze. Though, at some point I decided to switch over to Atom after being constantly bugged to pay for Sublime. I found Atom to be the best. Its UI is intuitive and package/theme installation is extremely easy to implement.

Those are only three editors. There are many more editors out there in the wild. Below is a list of editors you can experiment with.




“A text editor is at the core of a developer’s toolbox, but it doesn’t usually work alone. Work with Git and GitHub directly from Atom with the GitHub package.”

Atom is a convenient text editor for anyone who uses GitHub.


Visual Studio Code



Visual Studio Code is a code editor that allows you to debug, use Git control, and extensive customization.



Android Studio


The code editor for Android developers.


Sublime Text


Sublime Text is a text editor for code, markup and prose. It’s simple and lightweight.




“Vim is a greatly improved version of the good old UNIX editor Vi. Many new features have been added: multi-level undo, syntax highlighting, command line history, on-line help, spell checking, filename completion, block operations, script language, etc. There is also a Graphical User Interface (GUI) available. Still, Vi compatibility is maintained, those who have Vi “in the fingers” will feel at home. See runtime/doc/vi_diff.txt for differences with Vi.”



Neovim is a project that seeks to aggressively refactor Vim in order to:





An extensible, customizable, self-documenting real-time display editor. Emacs is the most customizable editor on this list because of a programmers ability to write their own extensions.



Spacemacs is a marriage between Vim and Emacs. If you can’t decide which one to use, you can integrate the features of both editors into a single editor.



A simple Vim-like editor.




A Mac-only text editor.



“Notepad++ is a free (as in “free speech” and also as in “free beer”) source code editor and Notepad replacement that supports several languages. Running in the MS Windows environment, its use is governed by GPL License.”



Jet Brains’ IDEs


Apart from editors, IDEs offer platform-specific tools for debugging and compilation of certain languages.

IDE for Closure

General purpose IDE

JavaScript IDE


Python IDE

Ruby IDE



Please follow and like us:
browser plugins

36 Browser Plugins You Can’t Live Without

April 26, 2019 Posted by Programming 0 thoughts on “36 Browser Plugins You Can’t Live Without”

Browser plugins simply make life easier for software developers who constantly need to test scripts, switch through tabs, and read darn good articles that help them get better at their craft. Juggling all of these priorities without leveraging the right tools can make the development experience that much more cumbersome. So, below, we’ve listed 36 browser plugins that you won’t be able to do without once you use them.



BlazeMeter | The Continuous Testing Platform

Test your script’s  performance easily.


Bug Magnet

This tool allows you to test edge cases of your app.


Check My Links

Broken links are bad for SEO. This tool tracks all of your links.


Exploratory Testing Chrome Extension

You can take screenshots and document detailed bug reports with this extension.


Note Anywhere

You can stick notes on web pages that will persist when you visit them again.


Page load time

The plugin’s name does as its name suggests: it checks the load time of a page.


Screencastify – Screen Video Recorder

You can use the free version to screen cast code or any particular bug that’s giving you problems.



If you want to imitate the font on any part of a web page, you can check the specific font type with this plugin.



If you want to know the tech stack of a competitor, wappalayzer gives you the insights you need.


CSS Peeper

You can exract useful CSS info from any website.


Funkify the Disability Simulator

This stimulates the disabilities of certain users so you can better implement accessibility options.


Awesome Screenshot

A great plugin for posting high quality screen shots onto Slack.



This plugin solves the tabbing problem by creating an interface that puts everything you need all in one place.

Extensions Reloader –

Helps with extension development by allowing you to quickly update (reload) your unpacked extensions


Refined GitHub

improves GitHub’s interface


User-Agent Switcher for Chrome

This can come in handy for testing front end code.


uBlock Origin

This offers security by blocking ads and filtering data.


Tree Style Tab

You can operate tabs in tree mode if you’re a tab hoarder.



Color picker from anywhere on the page



Password manager



shows the number of lines in a repo, somehow, to me, it feels important


Toolkit for YNAB is an amazing budget planning tool, this is an extension to make it even better



Accessibility testing in Chrome Developer Tools


VisBug –

Open source browser design tools


Sizzy –

Tool for developing responsive websites crazy-fast


Empty Cache Button

Toolbar button to empty the browser cache.


Html Validator

HTML validation inside Firefox. The number of errors of a HTML page is seen on the form of an icon and details in a developer tools tab.


Open With

Quickly open current web page in another browser.


Bookmark Tab Here

Adds context menu item ‘Bookmark Tab Here’ to Bookmarks Menus as an alternative bookmarking method.


Easy Youtube Video Downloader Express

Seems to be the best of the add-ons to download video from youtube.


Feed Preview

Because RSS feeds are not dead.


Firefox Multi-Account Containers

If you have multiple accounts on the same site, then this can really save you having to log out and log in again to switch accounts all the time.


Markdown Here

If you are a markdown aficionado this lets use write in markdown then click a button to toggle to formatted. Useful for web-based email (gmail, etc) and other sites like blogger or wordpress.


SiteDelta Watch

Regularly monitors a page for changes.


Cookie AutoDelete

When a tab closes, any cookies not being used are automatically deleted. Whitelist the ones you trust while deleting the rest.


Facebook Container

Prevent Facebook from tracking you around the web. The Facebook  Container extension for Firefox helps you take control and isolate your
web activity from Facebook.



Image sourced from

Please follow and like us:

Notes On Joe Armstrong’s Former Opinion of OOP

April 22, 2019 Posted by Programming 0 thoughts on “Notes On Joe Armstrong’s Former Opinion of OOP”

Joe Armstrong, the author of Erlang, in a 2010 interview mentioned his updated opinion of Object Oriented Programming (OOP). This term is ubiquitous now, but two decades ago, it was a paradigm shift that took some getting used to.

So if your question is about what I think about object oriented programming, I sort of changed my mind over that. I wrote a an article, a blog thing, years ago – Why object oriented programming is silly.

The interview doesn’t directly quote from the article, so we’ll take some notes from what a computer scientist thought may be the downfalls of OOP. The value that can achieved from diving into the past is to gain a deeper understanding of what OOP sets out to solve.

Armstrong began by trying to detail “why OOP sucks”. His main objections were:

1. The tight coupling of functions and data structures. Coming from a functional paradigm, the idea of entwining functions  with data structures seemed foreign.

Functions are understood as black boxes that transform inputs to outputs. If I understand the input and the output then I have understood the function. This does not mean to say that I could have written the function.

Functions are usually “understood” by observing that they are the things in a computational system whose job is to transfer data structures of type T1 into data structure of type T2.

Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage.


2. Everything has to be an object. This stems from the first point, but is further complicated by the fact that not everyone can agree on what exactly an object is. Objects have varying definitions: the above definition where functions and data structures are unified or another “radical” definition where any thing that is modular/polymorphic is an object. The first example, is the premise of Armstrong’s point and the second example undermines Armstrong’s entire argument. Since he implies that Erlang uses a functional approach, under the second definition of OOP, he’d been using OOP without realizing it.


3. His next two objections stem from multiple inheritance and and private states.

About inheritance

In an OOPL I have to choose some base object in which I will define the ubiquitous data structure. All other objects that want to use this data structure must inherit this object. Suppose now I want to create some “time” object, where does this belong and in which object…


About private state

The “hide the state from the programmer” option chosen by OOPLs is the worst possible choice. Instead of revealing the state and trying to find ways to minimise the nuisance of state, they hide it away.




Now, some of us take OOP for granted, though the paradigm does solve a great deal of problems. Still, the problems of the paradigm are worth delving into in order to make an informed decision about using the paradigm in projects that can mitigate its weaknesses.

Please follow and like us:
code ownership

Developers Talk About Dealing with Code Ownership

April 17, 2019 Posted by Programming 0 thoughts on “Developers Talk About Dealing with Code Ownership”

Eons ago(2006, to be exact), Martin Fowler outlined three types of code ownership: strong code ownership, weak code ownership, and collective code ownership. Strong code ownership involves modularizing parts of code and assigning each module to a specific developer. The developer would then make changes to that module alone. Modules that are slightly dependent would require the developer to have to communicate changes made. If a developer wants to make changes to modules he/she does not own, he/she would have to send requested changes to the the developer that owns the module.

You can start to see how problems may arise with this form of code ownership. You may have a situation where the bus factor comes into play: what happens when a member of that team suddenly quits and leaves behind months’ work of undocumented code? Martin’s point was that strong ownership was deeply problematic due to the fact that communication issues could hinder development speed.

There are just too many situations where something you need to do needs changes to other people’s code. Persuading them to make the change and waiting for the change often takes so long that it leads to delays and deeper problems, this is particularly galling when the change is a simple one.

Weak code ownership loosens the restrictions a bit by allowing developers to make changes to the modules of other developers while collective code ownership does away with individual ownership altogether. Whatever type of code ownership a company chooses to employ, there will be pros and cons. Examining a Hacker News thread, I was able to get a general sense of the type of code ownership being practiced today. Here are developers’ takes on the type of code ownership that their company uses.



In our case, teams don’t own projects/code-bases, they own “features” and “releases”.

About 67% of our code is some form of Ruby – some of it Rails, some of it custom Ruby code running in Kubernetes+Docker processing data.

The other 33% of our code is Rust – and not just service side code but Rust that has to run on multiple platforms with varying deep operating systems knowledge.

My team generally owns Features and Releases related to the Rust code because two of the three members are OS programmers by experience. That said, we don’t exclusively work on the Rust code and sometimes wander into the Ruby code base.

Similarly, other teams occasionally need to update the Rust code to generate some new data – a lot of that is pretty basic stuff and doesn’t require deep OS knowledge. So they’ll make changes there.

Since our stack is so heterogenous, it’s hard to have everyone work on everything. However, from what I know of most companies outside Apple/MSFT/Google/etc, they’re gonna fall in the “we own web services” where the only real bifurcation will be “frontend code” and then “middle-to-backend code”. Maybe throw in some apps as well.


Now all of that said – the reason we went to teams owning “features” and “releases” was to push folks to not be possessive of code. Stuff changes and it changes quickly, so there’s not much use trying to isolate folks. Document gratuitously, test heavily, and refactor often.



In my experience with several big organizations (20,000+ employees), they tend to have a home-grown application to track ownership of resources (assets) – including source code (repositories), and servers, databases, scheduled jobs (in autosys or suchlike).

Generally each of these entities is grouped into some bucket for an application / “system” / business area, and then that bucket has a few owners assigned, and also other non-ownership roles assigned (developer role can check in code to those repos, prod support role can log into the servers owned by the bucket, etc).

It’s generally heavily integrated with an LDAP directory, HR system to handle joiners and leavers, and also change management (Developers can only ssh to a production host during the change window of a change for that bucket).

These home-grown apps are generally old and clunky (written for IE6, with piecemeal improvements since then, that kind of thing), but hard to replace because they’re integrated with so many other applications.

I tend to think that this would be a good opportunity for some (startup) to do a great job of this as an off-the-shelf product, with good integrations with Linux + Windows authentication, an API, nice web app, etc – it would be very easy to do better than the in-house systems filling this niche.



At my current workplace, most top-level subdirectories in the source tree have a primary author. That person is (nominally) “owner” of that code. If they aren’t the one making changes, they’re almost always at least the one doing the code review.

Bugs by default get routed to the person who wrote the code (presuming that we can tell which code the bug is in). If that person finds out the bug is somewhere else, the bug gets transferred to a new owner.



I work for a large global company, and my department is building a fairly large Angular application. My team “owns” the primary project and several shared component libraries, and other teams build features for this project.

These teams are from all over the world, and many of us have never worked closely before this project began.

When we first started the project, we decided to split the UI into feature projects which are packaged and referenced in the common project. Each team owns their own feature projects; however, everyone is welcome to contribute PRs to any of the projects.

Some of our projects are shared and maintained by many teams, but we always have one team that owns each project.



Ideally you want to restrict changes to the owners (I don’t mean hard limits) So instead of having a team responsible for a part of code, they are responsible for the product. So if a new integration is needed, the owner is a service provider and should provide the interface or service for their client. That is fairly easy to setup with Microservices. However, that is a bit harder in a monolithic application code base.

In my workplace, we use the above model for almost everything. And there is one old code base where we use Github code ownership feature to force everyone to ask for a code review from owners. But even there, it doesn’t happen very often that people from different domain need to touch a code of another domain.

And that is the second point as well. Dividing responsibilities base on domains instead of components/modules between teams make it easier as most of the time they are not going to touch a code outside their own domain.



Everyone “owns” the code. Then there’s the guy you go to when it fails.

Helps to document things, so you at least have something to throw at people when they come asking.



Overall, collective ownership seems to be the dominant form of code ownership. The line between weak ownership and collective ownership begins to blur a bit when a code base is split into features where ownership is temporary. Even then, a subset of teams claim a collective ownership over a feature. The size of a company also seams to effect the type of ownership used. For example, a company that gives complete ownership of debugging to someone who is on call can do so if they’re company has 20 or fewer engineers. Once the number of engineers balloon in hundreds, then a collective ownership is needed to maintain productivity.

Please follow and like us:
front end

Guides and Cheat Sheets for Front End Developers

April 16, 2019 Posted by Programming 0 thoughts on “Guides and Cheat Sheets for Front End Developers”

Any front end developer would love to have the brain capacity to know everything about their field. Unfortunately, we can only know so much, especially when we’re new to front end development. Google can be an excellent resource, but sometimes you want a bookmarked document that you can pull up right away to find that specific function or style attribute that will solve your problem. Or, you might be waiting for code to compile and you’re just looking for great reads that will boost your skills. If you’re anyone of these people, check out this list of front end resources that we’ve curated for you.



If you have time to spare, you can read informative JavaScript articles written by industry heavyweights like Ady Osmani. Superhero.js serves as a repository for the top articles about “creating, maintaining, and testing a large JavaScript code base.”

Open Web CSS Reference

CSS often gets a bad rap for its unwieldiness.

However, the Open Web CSS Reference provides a categorized list of attributes that link to the W3C specification docs that teach you exactly how the attribute works.


OverAPI has resources for all types of developers and a few obvious useful resources for front end developers like CSS, Git, and JavaScript.

Dev Hints

The website’s founder, Rico wrote a dizzying list of front end framework and library cheat sheet that he’s shared to the public. It’s one of the most useful resources for modern front end development.

front end

The Ultimate Flexbox Cheat Sheet

Now that flex box has become more of a website design standard, it wouldn’t hurt to pour over the interactive documentation that you can find on this website.

Sass Guidelines

If you ever want to become Sass master, learning from Hugo Giraudel is not a bad way to go.

front end

Dev Docs

Dev Docs is the complete guide to everything there is to know about  languages and frameworks



Please follow and like us:
React developer

What It Means to be a Developer

April 10, 2019 Posted by Programming 0 thoughts on “What It Means to be a Developer”

As time progresses, technologies rise and die in the popularity rankings. New frameworks usher in a revolutionary paradigm that bring on a wave of new developers scrambling to become masters, only to have to repeat the same process three to five years later.  Those who decide to avoid the rush to learn new technologies sometimes find themselves aging with their current language or framework. This phenomenon begs this question: are you a better developer for adopting new frameworks? Developers have an insightful discussion about this question in regards to jQuery versus new frameworks like React. We’ve quoted the best bits for you here.


José Muñoz

I think what really makes or breaks a person as a developer is the ability to move data around. It doesn’t matter what language or framework you use, once you know how you want your data to flow through your application you can implement it however you like. Knowing how to handle data structures, how to communicate through the application, that is what makes you a developer, knowledge of the language is important but once you can handle data flow, then you can pick up a language/framework and get productive. but that is just my opinion of course.



I feel that this is old article is also related:…

However over the course of my professional carreer (almost 14 years now) I do feel that the industry is sort of… settling. Slowly. Oh, it’s still pretty much in turmoil and new ideas and frameworks still appear on a regular basis, but at the same time… some concepts, principles and ideas seem to have coalesced. They’ve been mulled around, variations have been tried, best practices have been found and are now accepted as the Right Way by almost everyone. And they’ve stopped changing. There’s an implementation or five in most popular languages that vary mainly by method names and no others are being created, because there’s just no point.

In backed this would be, for example, the areas of ORMs and Loggers. Take a bunch of active libraries and compare them. The differences are mainly in small details and naming, but the core concepts and patterns are the same. There’s no big innovation left there because we’ve already reached a state where they’re good enough for all practical purposes. In a similar way, GIT has won the source-control wars.

And I wonder if the same is happening in the front-end world? That’s not an area I’m deeply familiar with, but from the sidelines it also seems like there is a sort of settling. We have React and Vue which are based on the same ideas and everyone seems to be happy with them. There hasn’t been a major paradigm upheaval for years now.

Nobody can predict the future, of course, but I think that if you wish to go along the front-end route, then picking up React/Vue would probably be a good investment of time, likely serving you for years to come – if not the rest of your life.

In other words – even if you have fallen a bit behind the times, I think that catching up is easier than it seems.


Drew Taylor

I usually find myself asking the opposite when I am hiring new developers: if this person only knows React – are they even a developer??

Unlike Angular and Vue, React reinforces bad design patterns since the view and logic of a component are rarely separated, and this makes it difficult and messy to do team development.

For example, I recently hired a “React only” dev who seemed hungry enough to learn other things. Unfortunately, they quit after a week without contributing any reasonable commits. The final straw seemed to be a lack of willingness to understand proper MVC.

This was obviously an extreme case, but I’ve experienced similar things before among young devs of our current generation. Unfortunately, the same things that make React easy to learn mean many new developers won’t bother learning the reasons behind the decisions that power React or how to use web components without React.

In our current epoch, it’s important to learn how web components work, but the framework you use to achieve this shouldn’t matter, and there should be some emphasis on learning how web components work at their most basic and without any framework (W3C spec).



Fred Ross


  1. One does not. The vast majority of it is sturm und drang, which will leave yet another smear of legacy code across the landscape.
  2. That depends. The fundamentals aren’t changing. There’s nothing in React or the latest crazes in JavaScript that wasn’t already known in the 1970’s. There’s nothing in the NoSQL or database world that wasn’t already known in the 1980’s. It’s just showing up in a context that didn’t have them before. If you have enough fundamentals to learn the local details just in time, then you’re fine.
  3. There’s a place for all kinds of people. Don’t worry too much about definitions. One of my neighbors is an advertiser who also runs his own Linux fleet, does some rough machine learning, and handles his own business. Advertising is his core competency, and he’s just good enough at the rest to make it work and ask for help if he needs it.
  4. It depends how much complexity you’re willing to ignore at each layer. If by full stack you mean able to deploy a server, set up and administer the database, write and deploy a backend binary, and write the HTML and JavaScript that it serves, then, yes, it’s completely straightforward. Just be aware that each one of those layers can scale into a career in its own right. The problem is knowing what parts you actually need to know and what parts only apply when to problems where you need specialists and their more complicated tools.
  5. I have never used React. There isn’t a soul on the planet who would think that I’m not a developer.


Ryan Smith

If you aren’t using server-rendered React with ES2021, Typescript, Babel, ESLint, Prettier, custom WebPack configs, Jest, plus WebAssembly to handle the calculations all on top of Kubernetes, then what are you doing?

Jokes aside, I don’t believe it matters if you don’t use React. It may seem like you are being left behind, but there are tons of developers out there not using React, it just has the spotlight at this time. I bet that a lot of the React talk is also from developers that do not actively use React at their job or do not use it at all.

Even if the situation did arise where you would be forced to learn it or quit development for good, it is just a tool. Being a good developer is about more than just knowing the hot new framework/library. Learn the fundamentals that apply to any programming environment and you won’t have a problem. Learn the skills outside of programming that makes a good developer, there is a demand for that as well. Invest in yourself, not the next thing that people are flocking to and you will be in good shape. Chances are, the hot thing right now is not going to be the hot thing a few years from now.


Martin Himmel

Like others have said, don’t try to keep up with all of it. The best thing you can do there is be aware of what’s out there, but only jump on the things that interest you. You don’t have to (and can’t) do everything.

Silicon Valley is its own world of flash and hype – not an indicator of the rest of the tech world. I wouldn’t worry about keeping up there either.

Full stack is a fun one that can cause a lot of (pointless) arguments. A few years ago, I was told I was a full stack developer because I can code on the front and back end, and interact with a database. Prior to that, I just called myself a back end dev. But what he said made a lot of sense.

Look around today, and you’ll find wildly different views of what full stack is, or if it’s even possible for someone to be a full stack developer. Personally, I like the simple view (as with most things). If you can write server side and client side code, and can interact with a database, that sounds like full stack to me. Everything else is semantics.

And while a lot of job postings are for React developers, that’s hardly a requirement. I’ve never learned it. We don’t use it at our company. And when I interview people on technical skills, I typically look at raw language skills/usage rather than framework/library usage. My opinion is that if someone is proficient with a given language, they can pick up any framework if they need to. Going from framework to language is a bit trickier (I knew a “React developer” who didn’t know how to write a function in JavaScript – that still baffles me).

Bottom line – the web development world (or dev world in general) is vast. PHP is still going strong, despite the hate it gets from a vocal minority (Ruby experienced the same thing not too long ago). jQuery is still used all over the place. If those are your jam, and you’re able to build what you need to, then keep running with them. The ability to solve problems and create things is more important than the tools used to do so. Learn the things you want to learn – you’ll find a use for them. And don’t worry about learning Everything™.


Jacque Schrag

There are so many types of developers (front end, back end, full stack, software, websites, apps, etc.) that tying your “developerness” to your proficiency in one particular framework or library is only doing yourself a disservice. It’s hard to ignore that little voice in your head though when you see so many articles, courses, and job postings focusing on specific frameworks.



Please follow and like us:
time travel debugger

Mozilla is Working on a Time Travel Debugger for JavaScript

April 8, 2019 Posted by Programming 0 thoughts on “Mozilla is Working on a Time Travel Debugger for JavaScript”

Normally, when you want to debug software, you use a tool to pause execution in order to step through the code line by line. That’s after you’ve been able to isolate the bug. The problem is that for bugs that exist in complex systems, isolating the bug can be tricky. Some bugs are difficult to reproduce, because they don’t produce substantial effects, making them hard to pin down. For example,  logic errors can produce slightly unexpected results that add up over time. Tracking the source of the error by logging input and outputs can be painstaking.

If a developer could only look back in time to see the events that led up to the failure, they might be able to save time, thereby saving a company money. That’s the hypothetical that time travel debuggers put out. According to UndoDB, reverse debugging or time travel debuggers “can deliver significant savings. Mentor Graphics has reduced debugging time by 66% (two thirds) after implementing Undo’s reverse debugger for Linux, UndoDB. Take an average software developer earning $90,000. Currently they spend a quarter of their time debugging, costing $22,500 in wages. Reducing that by two thirds, creates a saving of $15,000 and increasing available developer time.”

Time travel debuggers have been available for GDB compatible programming languages like C/C++, Go, Fortran, Pascal, etc.

Then, you have projects like…

  • Chronon for Java
  • RevDeBug for .Net and C#
  • RevPDB for Python
  • Elm TTD for, as you can guess, Elm


What’s been missing from this list is a reverse debugging tool for the web’s favorite scripting language–JavaScript. Mozilla’s developers have been hard at work to come up with a time travel debugger for the browser. The technology is called Web Replay and is only available for macOS nightly builds.

Here are some of the features that are currently stable:

  • Ability to step back in code
  • Rewind to a set breakpoint
  • A timeline with record and replay markers, current position in time indicator, errors/messages
  • Retroactive console logging


Of all the stable features, retroactive console logging is the most interesting in that a large portion of front end debugging is looking at output logged to a browser’s console. How many times have you had to dig back into the source files to move console logs around to further isolate a bug? Countless times most likely. According to Mozilla, this headache is alleviated with Web Replay.

“The bug only needs to be reproduced in a recording tab once, and then console logs can be added which apply throughout the entire recording.  This is based on the log points feature in the debugger, which can be enabled with the devtools.debugger.features.log-points preference.  Set a breakpoint and right click on it to change it to a log point.

In a non-recording tab this will update the console whenever the log point’s location executes in the future.  In a recording tab, however, this will update the console with messages for every time the location has ever been hit.  This requires scanning the recording and the console will not update immediately.  These messages will show up on the timeline and can be sought in the same way as other console messages.”


There are several features that are still being worked on. Some of them are:

  • DOM/CSS integration
  • Object watching(logging changes to object over time)
  • Bookmarking points in recording
  • code path highlighting
  • Comparing executions(buggy vs clean code)


Web Replay may change the way front end developers code, but the complexity of time travel debuggers may limit its scope. Will developers accustomed to Chrome migrate to Firefox to take advantage of the new technology? If so, Google may also create a time travel debugger of their own. On the other hand, if the demand for time travel debuggers is minimal, the cost of developing such a complex tool may not be worth it to Google. Only time will tell whether Mozilla’s project will bear fruit.




Please follow and like us: