Laurence Gellert’s blog post on “What is a Full Stack developer” is a good summary on the high level expectations of what this phrase might mean to an employer or manager. He breaks it down into the following categories:
- Server, Network, and Hosting Environment.
- Data Modeling
- Business Logic
- API layer / Action Layer / MVC
- User Interface
- User Experience
- Understanding what the customer and the business need
Read his post for a more detailed breakdown if those 7 categories.
As John Simmons / Outlaw Programmer so succinctly put it recently:
…”full stack” developers (another way of saying they don’t want to hire enough people to do the job right) that can work on a technology mix that would make most real programmers wince in pain, and nine times out of ten, all they want is to hire someone long enough to clean up the last guy’s mess, or to implement some tech agenda based on some idiot manager’s wrong-headed view of how things should work.
Personally, I think John’s view is more accurate with regards to the reality of how employers use the term “full stack.” Laurence’s post is accurate at a technical high level but in my opinion is also growing obsolete, particularly items 2-5, when one starts to take into account emerging technologies such as AI, microservices, agent-based and context-based computing. These technologies completely reshape how we think about data modeling, business logic, the old Model-View-Controller paradigm, and user interfaces.
Just a random observation — I’m saddened when I encounter a management mentality that makes no effort to educate their junior devs so they can eventually become senior devs.
If you don’t have a decent knowledge of the programming language, framework and tools you’re working with, the way you “code” is like someone with a 3rd grade vocabulary trying to express a complex thought.
How do you educate junior devs?
- Code reviews by senior devs.
- Training sessions given by senior devs.
- Having time allocated to learn.
- Instilling an interest in learning!
Realistically though, nothing can overcome the “it’s a job, not a passion” attitude in the junior dev him/herself. If the junior dev has a passion for software development, they’ll most likely educate themselves on their own time, not just the company’s time.
But then, when they have learned, they’ll move on because the work environment suddenly becomes limited. An interesting dilemma for management, especially as they can now ask for a considerably higher salary than the company wants to pay for, which is why they hired junior devs to begin with.
Joel Spolsky, 18 years ago, wrote “The Joel Test: 12 Steps to Better Code“. Granted, it’s 18 years ago, but I thought it would be amusing to score my home work environment with my work work environment:
One point for each yes:
Do you use source control? 1/2 (yes, but not properly)
Can you make a build in one step? 1
Do you make daily builds? 0 – no, manually initiated
Do you have a bug database? 0 – not that I’ve ever seen
Do you fix bugs before writing new code? 0 – hahahaha
Do you have an up-to-date schedule? 0 – schedule, what’s that?
Do you have a spec? 0 – do you count screenshots in Excel as a spec?
Do programmers have quiet working conditions? 0 – unless you count needing to wear headphones
Do you use the best tools money can buy? 0 – VS2015, .NET 4.5, etc.
Do you have testers? 1
Do new candidates write code during their interview? 0 – I wasn’t.
Do you do hallway usability testing? 0
Do you use source control? 1
Can you make a build in one step? 1
Do you make daily builds? 0
Do you have a bug database? 1
Do you fix bugs before writing new code? 1/2 (I really try to practice this)
Do you have an up-to-date schedule? 0 – my clients are pretty loose about schedules…
Do you have a spec? 1 – …but they’re good about specs.
Do programmers have quiet working conditions? 1 (as in, total silence)
Do you use the best tools money can buy? 1
Do you have testers? 1 (assuming the client doing the testing counts)
Do new candidates write code during their interview? 0 – don’t interview people
Do you do hallway usability testing? 0 – unless the cats count.
It’s sad how my home environment scores considerably better than my work environment. No wonder there’s a “no telecommuting policy”, right?
I’ve been wanting to learn about SVG for a while now, and there are certainly any number of helpful websites on creating SVG drawings and animations. But I didn’t want to learn how to create static (or even animated) SVG drawings, I wanted to learn how to use SVG dynamically:
- Create, modify, and remove SVG elements dynamically.
Hook events for moving elements around, changing their attributes, etc.
Save and restore a drawing.
Discover quirks and how to work around them.
Read the rest of the article on Code Project!
Code is also on GitHub.
Object oriented programming and relational databases create a certain mental model regarding how we think about data and its context–they both are oriented around the idea that context has data. In OOP, a class has fields, thus we think of the class as the context for the data. In an RDBMS, a table has columns and again our thinking is oriented to the idea that the table is the context for the data, the columns. Whether working with fields or record columns, these entities get reduced to native types — strings, integers, date-time structures, etc. At that point, the data has lost all concept as to what context it belongs! Furthermore, thinking about context having data, while technically accurate, can actually be quite the opposite of how we, as human beings, think about data. To us, data is pretty much meaningless without some context in which to understand the data. Strangely, we’ve ignored that important point when creating programming languages and databases — instead, classes and tables, though they might be named for some context, are really nothing more than containers.
Contextual data restores the data’s knowledge of its own context by preserving the information that defines the context. This creates a bidirectional relationship between context and data. The context knows what data it contains and the data knows to what context it belongs. In this article, I explore one approach to creating this bidirectional relationship — a declarative strongly typed relational contextual system using C#. Various points of interest such as data types and context relationships (“has a”, “is a”, “related to”) are explored. Issues with such a system, such as referencing sub-contexts in different physical root-level contexts, are also discussed.
Read the full article on CodeProject.