30 Skills to Master to Become a
Senior Software Engineer
Dr. Sean Coates
February 6, 2016

About Me
• CTO at CircleBack Lending - Boca Raton, FL
• @fooyay
• scoates@circlebacklending.com

Why I Care
• hired 15 PHP developers in the past 18 months
• reviewed hundreds of candidates
• 95% of candidates simply do not measure up
• really wish more people embraced these skills
• we always need more senior software engineers

Why You Should Care
• Senior Software Engineers command higher salaries
• software development done the right way makes for
more reliable applications that are easier to expand
and grow
• well-rounded individuals are more likely to be tasked
with mentoring and leading others, to spread the
knowledge
• a lot less time wasted on technical debt

Fair Warning!
• this is a highly opinionated presentation
• I favor open source and PHP related technologies,
but there are certainly other paths to success
• your mileage may vary
• going to cover a lot of ground quickly - there is a
link to the slides at the end

If You Want to Keep Score
There are 30 skills, if you want to score yourself, give
your self points on each slide based on which
solution matches your practice.
• 0 points for poor
• 3 points for fair
• 7 points for good
• 10 points for excellent answers

1. A Server-Side Programming Language
In the early days of the web, this
might have been all you needed.
Also, we’re going to assume web
applications here - things are
different for other applications.
Other types of applications include
mobile apps, video game
development, data science
applications, embedded / device
development. These will require
different technologies and tools.

1. A Server-Side Programming Language
Poor: C, Fortran, COBOL,
Pascal, Lisp
Fair: Perl, Node.js, Scala
Good: Ruby, Java,
Python, C#
Excellent: PHP, of course.

2. Database Technology
The database is the foundation
of your application and can be
the source of many problems if
not implemented correctly.
Not only is it the retention of all
of your data, it also defines how
you are modeling your business
objects. Do it wrong, and you
can have all kinds of difficulties.

2. Database Technology
Poor: Just using flat files.
Fair: Mongo or some other NoSQL store only. Or, using a
commercial database product.
Good: SQL on MySQL or PostgreSQL
Excellent: Experience with an RDBMS (MySQL,
PostgreSQL, MariaDB Aurora), a columnar store (Amazon
Redshift), and a key/value store (Mongo, Redis, others).
Great with several DBs.

3. SQL and Data Modeling
Improper and inefficient use
of SQL is the most common
source of performance
problems in applications.
Data modeling covers
concepts like normalization,
naming schemes,
performance considerations.
It also communicates your
understanding of the data.

3. SQL and Data Modeling
Poor: Relies on ORMs to perform database queries.
Fair: Writes basic SQL. Works with a DBA to create tables.
Good: Good with complex queries. Understands
normalization. Has a style guide.
Excellent: Can explain a query plan. Handle extremely
complex queries. Strong skills with normalization and
modeling. Follows a style guide.

4. HTML
Used to describe web
documents, HTML5 has added
new features including
multimedia elements and
support for scalable vector
graphics and mathematical
formulas.

4. HTML
Poor: Relies on word processors or web publisher
tools to create web pages.
Fair: Can write documents in raw HTML.
Good: Uses some of the new multimedia features in
HTML5.
Excellent: Full understanding of HTML5. Developed
replacements for Flash components. Uses MathML.

5. CSS
Cascading Style Sheets
allow developers to control
the styling of web elements
independently of the HTML
source code. CSS3 adds
new features giving web
designers more control.
Now, Sass and other tools
are available to make writing
CSS easier.

5. CSS
Poor: Limited or no use of CSS styling.
Fair: Limited use of CSS files.
Good: Using Bootstrap and templates. Using other
CSS tools like Less.
Excellent: Extending past Bootstrap using Sass, highly
customized styles reflecting your corporate identity.

6. JavaScript
This browser-side language has
been used to push logic down to
the client, enabling for more
interactive websites.
Using techniques like AJAX it is
possible to create single-page
applications which are popular in
some places.

6. JavaScript
Poor: Spaghetti code that causes problems for everyone who
encounters it.
Fair: Simple animations and rendering.
Good: Can perform basic AJAX functions, making interactive
websites.
Excellent: Excellent use of AJAX, ECMAScript, JSON, and
related tools to create client-side programs that run in the
browser. Follows OOP techniques and pursues the same level of
code quality as seen on the server.

7. A Client-Side Framework
While most people at this
point are programming with
jQuery, there have been
several frameworks and
libraries in recent years that
greatly advance the state of
the art. And while it may be
premature to pick a winner
at this point, AngularJS has
the mindshare currently.

7. A Client-Side Framework
Poor: Limited or no use of jQuery or other tools.
Fair: Moderate use of jQuery only. May also use older
libraries like Ext JS and Prototype.
Good: Strong use of jQuery with one of the other
frameworks (Backbone, React, Vue)
Excellent: Robust use of AngularJS and jQuery,
supplemented with additional special-purpose JavaScript
libraries like D3.js.

7. A Client-Side Framework
It’s 2016.
There’s more to life than just jQuery.

8. Gulp
Gulp is a toolset that automates
part of your workflow. It covers
many areas including CSS
preprocessing, CSS and JS
minification, running unit tests,
refreshing your browser when
saved files change, and many
more.

8. Gulp
Poor: You’re doing these things mostly by hand.
Fair: A collection of random scripts. Apache Ant, YUI
Compressor, etc.
Good: Using an alternative instead, or just using Gulp for a
couple of things. Grunt, Broccoli, Brunch, Mimosa are
among the many options.
Excellent: Making use of Gulp to automate several parts of
your workflow.

9. Node.js
Server-side JavaScript got a huge resurgence with
the development of Node.js. We generally prefer PHP
for server-side development, but there are a lot of
great tools (Gulp included) that are built using Node,
so knowledge of Node has become required.

9. Node.js
Poor: No experience with Node.
Fair: At least one application using Node.
Good: Using Node to serve up pages instead of PHP.
Excellent: Automating several server-side operations
and development workflows using Node and tools
built on Node.

10. Virtual Machines
With virtual machines, you can
create a Linux environment
running on your laptop that
resembles your production
environment more closely than
just running applications
natively on OS X.
With Vagrant, provisioning
these virtual machines
becomes easier, often pre-
loaded with a full suite of
applications.

10. Virtual Machines
Poor: Still running on dedicated servers.
Fair: Passive experience with VMs, such as using
Amazon AWS.
Good: Using Vagrant to load and develop on Homestead.
Excellent: Creating your own VMs and sharing them with
your team, to save the work of installing all the various
libraries and tools.

11. SSH
OpenSSH is the most popular
implementation of SSH. SSH is a
key tool used for accessing
systems remotely, copying data,
and creating secure pipelines
between systems.
Working with SSH requires an
understanding of public-key
encryption.

11. SSH
Poor: the 80s called they want their telnet and ftp
back
Fair: Just ssh.
Good: Using ssh and scp.
Excellent: Proper use of public key encryption, key
sizes, ssh, tunneling, and secure copy.

12. Version Control
Being able to maintain
multiple concurrent versions
of the software is crucial for
professional software
engineering.
While git is widely used by
most, not everyone uses the
advanced features or follows
the gitflow method.

12. Version Control
Poor: Ancient systems like cvs, or often no use of
version control at all.
Fair: Instead of git, uses svn, Mercurial, Perforce, or TFS.
Good: Using git, typically with feature branches.
Excellent: Using git with
gitflow, with separate
develop, master, feature,
release, and hotfix
branches.

13. A Server-Side Framework
Laravel has become the most
popular MVC framework,
bringing not only a great
collection of best practices and
supportive ecosystem, it also
incorporates a great collection
of tools and components.
Examine Sitepoint’s 2015 survey
of PHP frameworks to see
Laravel ahead of all others for
use at work and in personal
projects.

13. A Server-Side Framework
Poor: A custom built, “in-house” framework. Or non-
MVC frameworks like Drupal, Wordpress.
Fair: Zend Framework 2, CodeIgniter, Phalcon, other
open source MVC frameworks.
Good: Latest version of Symfony, Yii, or CakePHP.
Also Rails (Ruby), Django (Python), Play (Java).
Excellent: Using Laravel and all of its components.
Watching Laracasts, following Laravel blogs.

14. An Object-Relational Mapper
With the rise of the MVC pattern and the Repository
pattern, ORM tools have been created to make life
easier and keep developers from writing the same
code in every application.
Most implementations follow the Active Record or the
Data Mapper pattern.

14. An Object-Relational Mapper
Poor: A custom built ORM, or worse, not using an
ORM at all.
Fair: Propel. Also, other ORMs in other frameworks.
Good: Doctrine - A Data Mapper implementation used
by many other frameworks.
Excellent: Eloquent - Laravel’s Active Record
implementation.

15. Database Seeding and Migrations
Database seeders are scripts that set initial data in
tables, or sometimes define the entire contents of a
reference data table.
Migrations are scripts used to create and alter
database tables as part of a software change.
These scripts ensure the database has the correct
data and schema across the various versions.

15. Database Seeding and Migrations
Poor: Database changes performed by hand.
Fair: Migration scripts are in use.
Good: Seeders and migrations are in use.
Excellent: Seeders and migrations are always used,
and maintained in version control. A key part of using
Laravel, for example.

16. View Templates
In the early days PHP itself
served the purpose of view
templates, but we’ve come a
long way since then and there
are very powerful tools available
now. These keep application
logic completely separated from
presentation logic, and allow
front-end developers to focus
on the view.

16. View Templates
Poor: In-house custom engine, or none at all.
Fair: Smarty - was good in its day but we have much
better options now.
Good: Twig, which has a great following.
Excellent: Blade. That means you’re using Laravel.

17. Security
Any real business has to be
acutely concerned with
security. Web applications have
a long history of being subject
to hacks due to weakness in
application security.
Hackers, script-kiddies, DDOS
attacks, corporate espionage,
negligence, and criminals
provide an ever-growing pool of
threats that we must be vigilant
against.

17. Security
Poor: Having a purely reactive approach.
Fair: Occasional security scans.
Good: Adopting some security techniques and scans,
often in response to an audit.
Excellent: Guided by a
CISO, following OWASP,
building a security maturity
model, making security a
part of every code review.

18. Creating APIs
Most systems will end up talking to other systems.
Sometimes it’s a simple matter of breaking up the
monolith, and sometimes it’s relying on 3rd-party
services outside your company in order to more
efficiently perform your business functions.
The connections between these systems need to be
developed in a clear, predictable, manageable way
that is easy to improve and expand.

18. Creating APIs
Poor: Custom-built XML-based APIs, trading
messages via csv files or fixed-length records.
Fair: Good old SOAP. APIs are documented but dated.
Good: REST with XML, but some of the above is
missing.
Excellent: Sending JSON data via REST commands,
properly versioned, documented, and authenticated.
Asynchronous messages land in queues. Use industry
standards where available.

19. Composer
As applications increase in
size, the number of packages
included grows dramatically.
Using a tool like Composer
allows you to manage your
libraries and dependencies
easily.

19. Composer
Poor: Including libraries and automatically asking for
the latest, untested version. Every build is an adventure!
Fair: Including hundreds of libraries and packages, not
sure if they are all still in use.
Good: Using Node’s npm, or Ruby’s bundler. Depending
on outside repositories to build.
Excellent: All of your libraries are managed by
Composer, and local copies of properly vetted versions
of libraries are kept.

20. Packages
Don’t reinvent the wheel.
Don’t spend countless
resources developing some
common functionality that
can be had much more
easily by using a package or
library.

20. Packages
Poor: Custom-build all the things.
Fair: Using old, dated packages. Struggle with
maintenance.
Good: Using the latest packages, even some obscure
bleeding edge ones.
Excellent: Recognize which packages and libraries to
use, which versions are best, and stick to those
which are popular and widely used.

21. Creating Dummy Data
When creating large amounts
of test data for your test
suites, you want that data to
look realistic. At the same
time, using production data is
considered to be too risky.
Fortunately, there are tools
available to help. Faker is
among the best of these.

21. Creating Dummy Data
Poor: Not creating any test data. Or using production
data and exposing customer private information to a
test environment.
Fair: Copying production data and then writing scripts
to scrub out the private information.
Good: Using your own scripts to generate test data.
Excellent: Robust use of Faker to generate test data.

22. Unit Testing
One of the biggest indicators
that separates the senior
software engineers from the
rest of the pack is the use of
unit testing and test driven
development.
When people say they don’t
“have the time” to write unit
tests, they always spend ten
times as long fixing bugs and
battling technical debt.

22. Unit Testing
Poor: Not writing tests. Thinking you don’t have the
time to write tests.
Fair: Writing some phpunit tests after the fact, aiming
for better code coverage.
Good: Doing TDD with phpunit or phpspec, covering
happy path and some failure cases.
Excellent: Doing BDD with Behat and TDD with
phpspec. Covering all your edge cases.

23. IDE
Many old-school developers
often rely solely on a text
editor to write their code.
Others use advanced editors
with nice plugins and
integrations. An integrated
development environment
provides much more
functionality and power to the
skilled developer.

23. IDE
Poor: Simply using a text editor.
Fair: Sublime Text or vim power-user with lots of
plugins and integrations.
Good: Using other IDEs like Eclipse.
Excellent: Using PhpStorm with XDebug and taking
full advantage of its features.

24. NoSQL
Sometimes known as document
stores or key-value stores, NoSQL
databases like MongoDB,
CouchDB, Redis, Memcached,
Dynamo, Cassandra and others
provide a simple way for storing
unstructured data. Also used in
situations where database
schema changes rapidly.
While the best product depends
on the application, there are
certain guidelines in the use of
NoSQL databases.

24. NoSQL
Poor: Storing data in text files.
Fair: Storing data in obscure proprietary databases
(Access) or custom-built databases. Or using a NoSQL
database for everything.
Good: Using a NoSQL database for storing session data
and a couple other common applications.
Excellent: Using appropriate NoSQL databases for certain
applications involving unstructured data or data with single
keys. Using RDBMS for highly structured, relational data,
and columnar stores for data warehouse applications.

25. Automated Deployment
The process of assembling
software, running tests,
integrating libraries, compiling
code, and building packages
can be complex and prone to
error. Thus it is wise to apply
as much automation as
possible to these processes.

25. Automated Deployment
Poor: No automation, processes handled manually.
Fair: A random collection of custom scripts.
Good: Some use of Jenkins, or using other CI tools
like Bamboo or Travis.
Excellent: Using Jenkins with the Jenkins Best
Practices.

26. Business Analysis
This is the art of identifying
business needs and
determining solutions.
Typical work products
include storyboards, use
cases, UML diagrams,
flowcharts, wireframes, and
requirements documents.

26. Business Analysis
Poor: You receive and react to random requests from the
business all the time.
Fair: You’re working with excessive business
requirements documents filled with outdated information.
Good: You can develop robust functional specifications
and have a strong understanding of the business.
Excellent: Not only can you write excellent specifications,
you also have a deep understanding of the business and
help design new processes and systems.

27. Project Management
When projects grow in size
and require the efforts of
several individuals or teams, it
becomes necessary to
manage the project’s
dependencies and resource
constraints.

27. Project Management
Poor: No planning or coordination.
Fair: Proactive efforts are made, planning occurs.
Good: You’re using some project management tools.
Plans are documented and tracked.
Excellent: You can coordinate the efforts of several
teams while maintaining the Agile principles, making
strong use of tools that integrate with the ticket
tracking system and other tools.

28. Ticketing System
With a good issue tracking
system, you not only
manage the present
requirements, you also
provide historical statistics
and reference material.

28. Ticketing System
Poor: Physical tickets like post-its or 3x5 cards.
Spreadsheets.
Fair: Older open-source tools like Mantis and Bugzilla.
Other commercial products lacking in features.
Good: Other professional tools such as Rally, Pivotal
Tracker, Microsoft TFS. A healthy implementation of
Redmine also works.
Excellent: Using JIRA to track all issues, bugs, projects,
and desired features. Customizing JIRA to model your
company’s workflows.

29. Teamwork
A highly effective team can
accomplish much more than
individuals acting separately.
Strong teams also learn faster
and lower defect rates.

29. Teamwork
Poor: A cowboy culture of rock stars, coding ninjas,
and primadonnas.
Fair: A co-located team working on the same project.
Good: Peer-level code reviews using pull requests. A
collaborative culture.
Excellent: Using pair programming regularly. Team in
constant communication via Slack or HipChat.

30. Patterns of Enterprise Engineering
In software development,
common problems reoccur
regularly. This leads to
general, re-usable solutions.
By learning these patterns,
we gain a common language
for describing these
situations and, at a high
level, their solutions.

30. Patterns of Enterprise Engineering
Poor: Ignorance of patterns leading to random
solutions each time.
Fair: Occasional use of a few patterns.
Good: A software architect on the team understands
several common patterns and provides guidance.
Excellent: Everyone on the team understands the
patterns widely used in solving the company’s
software problems. Pattern solutions used
appropriately (don’t overdo it).

So, that’s all you need to know.
Now you’re ready to be a senior software engineer!
You got 300 points, right?

Except…

Okay, There’s 30 More Things
• Homebrew
• /etc/hosts, dnsmasq
• sprites
• disaster recovery
• SOLID principles
• CDNs
• master data
management
• giving presentations
• TLS
• physical/mental health
• Ansible (chef, puppet)
• Kanban
• A/B testing
• prototyping
• UI/UX
• database administration
• AWS
• Selenium
• time management
• style guide
• Agile principles
• data modeling
• interviewing
• SEO
• R (SAS, NumPy/SciPy)
• physical security
• websockets
• negotiation
• columnar databases
• exception handling,
alerting, and reporting

Actually…

It Never Ends.
Never stop learning. If you’re not learning new things
all the time you’ll never keep up.
That’s the joy of this business. You never run out of
exciting new things to learn.

Thanks for listening.
Dr. Sean Coates, CTO at CircleBack Lending
@fooyay
scoates@circlebacklending.com
legacy.joind.in/16794
now hiring in Boca Raton, FL!