On the top of Google news today was a Newsweek post in which (my bold):
Another panelist, Gina Sosa, said of the allegations by Ford: “I mean, we’re talking about a 15-year-old girl, which I respect. I’m a woman. I respect. But we’re talking about a 17-year-old boy in high school with testosterone running high. Tell me, what boy hasn’t done this in high school?”
Excuse me, Gina, but I’m one of those boys that didn’t do that and would never do that. And I knew a lot of other 17 boys that were my friends that would never do that.
Sad, that Newsweek gathered a “panel of Republican women” and one of them said this.
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.