Wednesday, August 06, 2014

I will be conducting another Neo Technologies sponsored, one day training class on August 29th, 2014 for the Vancouver graph database user group (join us here). The class is designed to maximize the learning over the 8 hour course and teach students what graph databases are, how they differ from RDBMS systems, the data model (or lack thereof), Cypher - the query language and how to build and use graph databases (the bulk of the class).

About Neo4J

Neo4J is the world's leading graph database, meaning it is used by more customers than any other graph database. It offers several advantages over fixed schema databases, especially for startups given the immaturity of their data models. Neo4J does not require a schema like Relational DataBase Management Systems (RDBMS). Instead, Graph databases save data as "Nodes" that are connected with "Relationships". Nodes and relationships both have "properties" which si how humans think about concepts in the real word. Nodes may be arbitrarily added or removed without re-writing an entire database schema, a true savings of costs and effort.

The Neo4J implementation of a graph database has become the industry standard. Cypher itself, a language similar to the Structured Query Language (SQL) has become a sort of Pseudo standard within the space. The course will cover the basics of Cypher and some advanced topics like sorting and filtering return values.

There are still seats available as of the time of this article. if you will be in Vancouver at the end of August, please come out and learn some Neo4J. The cost covers the logistics so the course is basically almost free.

Tuesday, August 05, 2014

We have been asked many times to define the differences between Senior and Junior programmers. While there is no exact answer, this blog post attempts to clarify what we look for when hiring developers at different levels.

The labels “Senior” and “Junior” are difficult to comprehend as they can sometimes be bestowed on the same developer depending upon the context of assessment. A developer may be considered “senior” with respect to the .NET development platform while at the same time be considered “junior” at HTML5 and some of the more recent related technologies. Experience clearly plays an important role in working with multiple technologies as well. Developers who may intrinsically understand the internal nuances of a complex platform like J2EE may be lacking the full practical experience that only comes from using multiple versions of the language and migrating from one to another. In some cases, a developer who is knowledgeable about topics in great depth may actually lack the full breadth of experience. This latter experience augments the deep knowledge of more specific facets since the entire evolution of one part of that language may be a reaction to a shortfall or persistent problem a previous version had. Such context-specific assessments require those who assess developers to remain somewhat flexible in their own judgments concerning experience vs theoretical knowledge. Both help a developer get the whole picture of each language or platform.

Of course, the differences could be explained with a bit of humor. The following diagram helps non-developers understand the differences in mind-sets between the two groups.

To begin to place some formal constraints around the differences, the descriptions can be summarized as follows:

Junior developers are still acquiring many of the skills their senior counterparts possess. The reality is that the senior programmers only achieve the extra skills through experience and perseverance. Many of the skills cannot be taught in a classroom as real life experience is required to guide the developers knowledge bases. Junior programmers are often given tasks to do, but are seldom handed projects. A task takes no longer than a couple of weeks overall and often is not delivered as a customer-ready deliverable. The junior programmers often do not gather requirements and in many cases are not provided the details of “why” they are doing a certain task. They typically do not talk to customers or if they do, the interactions are often very limited. A junior programmer will not feel comfortable training other developers nor will they lead teams. They often need reviews from senior developers. On version control systems, an administrator will not provide the credentials or bestow the rights to “destroy” code or projects and are not permitted to over-write the work of others. They typically dream of working on bigger projects and are well situated to handling smaller tasks but cannot provide customer-ready solutions to business problems.

By contrast, a senior developer is given projects to do as opposed to tasks. Some projects can last up to 6 months and require the senior developer to gather requirements. They often will be part of the team that talks to customers directly and will develop “solutions” to those problems and explain their ideas to the customer. Senior programmers tutor juniors and provide paths for juniors to keep acquiring new knowledge. A senior developer will usually have “destroy” rights on version control systems and uses them to help others learn the errors of their ways. The senior developer dreams of designing, not coding but hacks all the time.

The following chart outlines some other fundamental differences we typically use to delineate a senior programmer from their junior counterparts.

Task

Junior

Senior

Codes
up a given library

Yes,
task does not require knowledge of entire application. When given the task, the API will be
constrained and specified. All work
will be to ensure the library works as intended.

Yes
but can also engineer the library. This means defining the API and parameter
list, understand what classes or libraries may call it and how it has to be
architected (static classes?
Prototypes with concrete classes inheriting? Method signatures?)

Understands
the method signatures

No
– is only proved with the specification and the API signature.

Yes,
additionally, the senior developer can architect the class to accept multiple
parameters and figures out the correct order, data types and tests.

UML

Junior
Developers are not required to interpret UML of an entire system

Senior
developer must understand the system architecture. In addition to the class function, needs to
understand the class relationships and methods. Typically uses class new
diagrams, sequence diagrams and use case diagrams as well as other similar
artifacts.

Class
methods

Juniors
usually scope everything to private.

Can
determine how to mutate the access modifier to public, private, protected etc.
based on class use and function. Understands the rationale behind the
decisions.

Knows
when to develop simple API’s vs complete web services

No

Yes

Data
types

Does
not understand which data type to use if not told. Does not differentiate big endian vs.
little endian types.

Can
study a system and determine which data types are optimal for each API call.

Multi-thread
experience

Basic
– understands the concepts.

Advanced
– uses keywords like “volatile” to denote variable uses when multiple threads
may be trying to mutate values concurrently and knows how to mitigate these
scenarios.

Multi-thread
experience

Does
not understand thread controllers

Uses
thread controllers to ensure optimal operations for all class instances. Can
take advantage of multi-core processors.

Codes
first to get a head start. Can only be given tasks and not projects

Does
architecture first properly to ensure the system will work as required. Can be given entire projects and will write
any missing architecture docs to ensure others have documentation.

Documentation

Does
not write

Knows
it must be written and ensures it is done along the way.

Durability

Writes
code.

Writes
code to be maintainable over time.

Problems

Brings
problems to Sr. programmers

Finds
solutions to problems

Estimates

Guesses. Cannot envision all code in their head
without writing some so cannot be accurate in estimates. When given, estimates are often provided in
< 1 hour

Can
estimate a complete project, Designs complete code in mind before starting to
code in order to provide a realistic estimate. Estimates take at least one week and asks
many questions to ensure complete understanding of requirements.

Motivation

Needs
to be motivated

Knows
how to motivate other coders to complete the project and produce quality
code.

Vision

Only
sees what is in front of eyes

Can
foresee problems others do not yet see and knows the best ways to eliminate
them. This work is often unrewarded as
the product owner often thinks the problem never was, does not appreciate the
Sr. Coders work in avoiding it all together.

Pin it!

SHARE!

If you are helped by this blog in any way, or just find the contents interesting, please give it a share to help keep me publishing. Shares help drive my advertising revenue which makes me more likely to write articles to help people in the future. Thank you in advance!