Want to become a senior dev? I’ve made this Senior Developer Roadmap 🗺️ just for you!
This is my take on what skills and traits you need to grow into a senior position. It’s still a work in progress, so expect some improvements in the future.
TIP: Click on the image to load the full resolution version.
Here’s a quick rundown of the content included:
Prerequisite: Previous Role’s Roadmap
You need to have gone through the previous roadmap for your role as outlined in roadmap.sh. This is important since your team will look to you for technical guidance in your specific stack.
As a senior developer, you need to uphold quality not just for your
own work, but in the work of your team. This means creating standards,
doing reviews and documenting as needed.
A senior role is characterized by making good decisions. There are
many technologies we can use to create products so choosing the right
one for the project is important.
Another task of a senior dev is turning ideas into practical
solutions. Not only do you build new features, but you also have to fix
and improve existing ones with an eye towards reliability and
It’s a misconception that the senior dev sits behind closed doors
coding all day. You also need to be able to convey your ideas well, both
to dev teammates and nontechnical colleagues.
Sure you might think this is a PM’s job, but remember that you’re
also tasked to create solutions, which is part of the project planning
process. So know how your company’s project planning process works so
you can work effectively within it.
One of the most gratifying tasks of a senior dev is improving the
technical capability of the team. This happens through mentorship.
Finally, the best trait of a senior dev is being a good leader of the
team. This is also the toughest part of the journey, since you need to
cultivate new patterns of thinking that involve raising up others more
Got comments, feedback and questions about it? Just email me or comment below!
If you want to get a sense of which level you’re on in your engineering career, here’s a chart made by Mozilla of how their career ladder for individual contributors work. Click here for the hi-res version
Once a webpage leaves your servers, anything can happen to it. Sometimes, the client’s browser tries to execute scripts against your page that range from the benign changing of font colors to nastier XSS attacks that manipulate and steal user data.
This is where a Content Security Policy comes into play. It basically instructs the browser what kinds of content is allowed to load for your site. This includes restricting loading of external scripts, images and any other files that might want to load on top of your page.
Your CSP is set up! You can view the directives in vendor/spatie/laravel-csp/src/Policies/Basic.php . This is a bit restrictive though, so you might want to publish your own policy instead. Here’s one I used recently:
class MyPolicies extends Policy
public function configure()
You can learn about what the different policy directives mean in the Content Security Policy Quick Reference Guide. In my own policy above, I allowed image blobs and base 64 image data, as well as letting Google in because of Recaptcha and Analytics.
Create your new policy. I saved mine in app/Services/Csp/Policies/MyPolicies.php. Feel free to use my own policy above as a starting point for your own.
Go to config/csp.php
Replace the content so that it will use your new policy instead
* A policy will determine which CSP headers will be set. A valid CSP policy is
* any class that extends `Spatie\Csp\Policies\Policy`
// replace the default policy
//'policy' => Spatie\Csp\Policies\Basic::class,
'policy' => MyPolicies::class,
* This policy which will be put in report only mode. This is great for testing out
* a new policy or changes to existing csp policy without breaking anything.
'report_only_policy' => '',
* All violations against the policy will be reported to this url.
* A great service you could use for this is https://report-uri.com/
* You can override this setting by calling `reportTo` on your policy.
'report_uri' => env('CSP_REPORT_URI', ''),
* Headers will only be added if this setting is set to true.
'enabled' => env('CSP_ENABLED', true),
* The class responsible for generating the nonces used in inline tags and headers.
'nonce_generator' => Spatie\Csp\Nonce\RandomString::class,
Now that you have your CSP set up, you can check it by entering your site in Google’s CSP Evaluator. Mine showed this:
Of course, this is just a guide, no need to be alarmed if it says high severity. For me, the script-src finding was okay because I needed to allow Google scripts to run on the site. So evaluate your results based on how your webapp works and don’t force your site to get all green checks in this test.
Hope to see more people securing their site via CSP!
Ah, the pitfalls of a popular framework. Everyone uses it therefore it’s easy to get coding help but everyone also abuses it so any and all exploits will be sussed out.
One of these is such a basic feature that I think everyone should turn off: XML-RPC. I won’t go into all the details but suffice it to say that it’s bad. And if you do want to access your WordPress site remotely, say like a headless CMS, then use REST instead of XML. It’s much better for your health, trust me.
Here’s how to disable it:
Go to your site root’s .htaccess file
Insert this snippet at the top:
# Block WordPress xmlrpc.php requests
deny from all
You should be good. Double check if it worked by testing it here: https://xmlrpc.eritreo.it/ You should see that comforting red X in the next screen.