Category: Programming

A big part of my work has to do with code. I’ve worked as system administrator – installing, patching, and configuring someone else’s code. I’ve worked as independent programmer, writing code on my own. I also programmed as part of the team. And on top of that, I worked as Team Leader and Project Manager, where I had to interact a lot with programmers. Programming world on its own is as huge as the universe. There is always something to learn. When I find something worthy or something that I understand enough to write about, I share it in this category.

What is a Senior Developer?

I’ve been hiring, firing, and working with developers of all sorts for the last couple of decades. In those years, I realized that each developer is very unique – their strong and weak sides, knowledge gaps, working rhythm, social interaction, communication abilities, etc. But regardless of how unique each developer is, it is often useful to group them into expertise levels, like junior and senior. Companies do that for a variety of reasons – billing rates, expectations, training required, responsibility, etc.

And this is where things get tricky. One needs a good definition of what a senior developer is (other definitions can be derived from this one one too). There is no standard definition that everybody agrees upon, so each one has their own.

I mostly consider a senior developer to be self-sufficient and self-motivated. It’s somebody who has the expertise to solve, or find ways of solving any kind of technical problems. It’s also someone who can see the company’s business needs and issues, and can find work to do, even if nothing has been recently assigned to him. A senior developer would also provide guidance and mentorship to the junior teammates. I’ve also came to believe that people with the real expertise have no problem discussing complex technical issues in simple terms, but that’s just a side note.

Anyway, recently, I came across this very short blog post, which sent me a spree of pages, charts, and discussions:

Because of this “What is a senior developer?” conversation on Reddit, I am reminded of the Construx Professional Development Ladders, as mentioned to me long ago by Alejandro Garcia Fernandez. Here is a sample ladder for developers.

The original article for the Reddit discussion – “The Conjoined Triangles of Senior-Level Development” is absolutely brilliant. In the beginning it provides a chart of the conjoined triangles of senior-level development, which reflects my definition and understanding:

But it doesn’t stop there. It dives deeper into the problem, and, eventually features this Venn diagram:

.. and more. By now, I’ve read the article three times, but I keep coming back to it – it just makes me think and rethink over and over again. Once it settles in my head a bit, I’ll look deeper into the Professional Development Ladder and it’s example application to the senior developer.

Overall, this is a very thought provoking bunch of links.

Kali Tools – Linux distribution for penetration testing

Kali Tools – a special purpose Linux distribution for performing penetration testing. A long list of tools is split into the following categories:

Information gathering
Vulnerability analysis
Wireless attacks
Web applications
Exploitation tools
Forensic tools
Stress testing
Sniffing & spoofing
Password attacks
Maintaining access
Reverse engineering
Hardware hacking
Reporting tools

WTF : The Inner JSON Effect

I’ve seen my share of horrible systems, but I haven’t seen anything this bad:

“So you have ‘customers.json’ and ‘customers.js’. The JSON file is the metadata and the JS file has all the code. So the list of functions in the JSON file tells JDSL to look up those revisions of the JS file to find what functions are available. In this case the actual code is in revisions 568, 899, 900, 901, and so on.”

Although I’ve seen a system before that breaks when adding code comments to certain files (as it was parsing source code with regular expressions, rather then with the language parser):

“Well, yes. I added a few code comments, trying to–”

“You can’t use comments in JDSL!” Tom shouted. “THAT’S WHAT BROKE IT!!”

Jake stayed silent, trying to process how code comments could wipe out a customer database. Tom continued after a pause. “I haven’t added comment support to JDSL, so the runtime executes comments like normal code! You must have had database updates in some comments?!”

“Well, yeah, I put a couple short syntax examples in a comment to clarify–”

Tom burst to his feet. “I knew it! You BROKE IT!” He turned to face the VPs. “I can’t deal with coders who don’t understand the system! You will either fire Jake…or I quit!” And he stormed out of the room.

Git from the inside out

Git from the inside out – must be the best thing I’ve ever seen on how git works. Everybody knows that git is awesome. Most know that git is implemented with graphs. But not many know how exactly git stores the project history and how it is affected by different git commands.

And if you are feeling adventurous, there is this:

After reading, if you wish to go even deeper into Git, you can look at the heavily annotated source code of my implementation of Git in JavaScript.

Which, among other things, includes “Git in six hundred words“.

Packer – a tool for creating VM and container images

With the recent explosion in the virtualization and container technologies, one is often left disoriented. Questions like “should I use virtual machines or containers?”, “which technology should I use”, and “can I migrate from one to another later?” are just some of those that will need answering.

Here is an open source tool that helps to avoid a few of those questions – Packer (by HashiCorp):

Packer is a tool for creating machine and container images for multiple platforms from a single source configuration.

Have a look at the supported platforms:

Amazon EC2 (AMI). Both EBS-backed and instance-store AMIs within EC2, optionally distributed to multiple regions.

DigitalOcean. Snapshots for DigitalOcean that can be used to start a pre-configured DigitalOcean instance of any size.

Docker. Snapshots for Docker that can be used to start a pre-configured Docker instance.

Google Compute Engine. Snapshots for Google Compute Engine that can be used to start a pre-configured Google Compute Engine instance.

OpenStack. Images for OpenStack that can be used to start pre-configured OpenStack servers.

Parallels (PVM). Exported virtual machines for Parallels, including virtual machine metadata such as RAM, CPUs, etc. These virtual machines are portable and can be started on any platform Parallels runs on.

QEMU. Images for KVM or Xen that can be used to start pre-configured KVM or Xen instances.

VirtualBox (OVF). Exported virtual machines for VirtualBox, including virtual machine metadata such as RAM, CPUs, etc. These virtual machines are portable and can be started on any platform VirtualBox runs on.

VMware (VMX). Exported virtual machines for VMware that can be run within any desktop products such as Fusion, Player, or Workstation, as well as server products such as vSphere.

The only question remaining now, it seems, is “why wouldn’t you use it?”. :)