30 skills to master to become a senior software engineer
TRANSCRIPT
30 Skills to Master to Become a Senior Software Engineer
Dr. Sean CoatesFebruary 6, 2016
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
legacy.joind.in/16794
now hiring in Boca Raton, FL!