As Developers, we’re often met with many different technologies, all new and foreign to us, and with someone telling us it’s the next big thing and we must learn it. I’ve listened to those people for years now and I’ve found some patterns for a suitable abstraction of what types of technologies should be in your toolbox. So here there are…
Firstly, I believe in the full stack dev mentality. I genuinely believe any developer should be able to do any task. That’s not to say there isn’t room for specialists, or full time certain-technology-only-developers, but I believe the best developers are the ones who mix and mingle with other technologies, bringing the patterns back to their “home” language, keep their learning skills sharp and who keep their mind open. With that said, I believe that developers should know a bit of everything, and here are the bases I’ve covered in my career. So what should be in a minimal toolbox for every good developer?
A Web Framework
This could be Ruby on Rails, Node.js, PHP, Phoenix, Perfect, etc, it doesn’t really matter. The point here is the idea of what a web framework should do – it create, reads, updates and deletes (CRUD) data from a database in response to a given HTTP request, and provides a suitable response. It might also kick off background tasks or add data to a queue/stream to be processed later.
A Task Runner/Scheduler
As mentioned above, a task runner is good for task that need to be run at some point in the future, or on a schedule. This could be Cron, sidekiq, Verk, even windows task scheduler. The idea here is to learn that some tasks need to be happen relative to time itself or relative to a request, but can be performed at a later time. As an example, processing a file upload; the response is ‘we got your file, thanks!’ but the background task could be the actual processing of the file and perhaps sending an email when the processing has finished.
Queue Software
This could be RabbitMQ or Amazon SQS or Azure Queue Storage/Message Bus. The idea here is that some software on the backend are named “producers” and they put data on the queue to be consumed by “consumers”. This lets you start or stop more consumers based on load on your server.
Stream Software
Similar to queuing, where items entering the queue are removed by the consumers, streaming software lets blobs of data flow past like a river and many consumers can react to what they see go past. This could be Kafka, Amazon Kinesis etc. The difference between a queue and a stream is also important, but this isn’t the time to cover that.
A Frontend Framework
This could be EmberJS, Angular, React+Redux, Vue.js, even jQuery! The idea of knowing a front end framework is to learn such interesting lessons as browser quirks, trans/compilation of languages, web debugging/inspecting, responsive design, de/serialization of data and UI/automated testing.
A Mobile App Framework
While not essential, I think it’d be useful to learn at least one mobile platform, such as iOS, Android or Windows 10 Phone. It could also include Cordova, React Native, or even Unity. Mobile programming teaches a lot about programming with tech constraints and weighing up a lot of user experience trade offs such as small screen size, battery life and privacy. The IDE support also makes for a pleasant environment to work in.
A Scripting Language
There are times where you need something quick and dirty for a bit of scripting. This may be AppleScript, Bash, Powershell, Python or Ruby. Just something to automate a task for a one off or to run every now and again with Cron or similar. Every good dev should know when and where to write something quick and hacky, and having knowledge of how to do so is great.
A Relational Database
This could me MySQL, PostgreSQL, MS SQL Server or anything similar. The idea here to learn about how relational databases work and how records are stored and searched for. It would be good if you learned the benefits of stored procedures vs in code procedures and what kind of optimisations can be made at storing and retrieval time.
A Non-relational database
There are more and more of these, and each are optimised to do a certain task, such as ElasticSearch for search or Druid for time-based data. This could also include more general purpose NoSQL databases such as MongoDB or DynamoDB. You should try to understand the difference between NoSQL databases and SQL databases (non-relational vs relational)
And that’s your toolbox! With these you could probably build anything you wanted, or contribute you almost any software business. Of course, you don’t have to learn all of them in a week, it’ll take a few years. You also don’t need to be passionate about all of them, you can pick and choose – it’s your career. There’s probably some other technologies worth mentioning that I have forgotten, so gently calmly mention them to me! Good luck :)
This is the 12th post in my Junior Developer Diaries blog series. I’m writing more every week, and you can sign up to hear more and read previous posts on my website.
Top comments (45)
I feel like this should have been called "every web and app coder", not "every coder". Nearly all of these are web technologies... Or is this just a symptom of the death of general purpose computing?
"I genuinely believe any developer should be able to do any task." So where's the linux kernel drivers? Or your gui toolkit? Or your differential equation solver? I know so many coders that never touch any of the technologies you mentioned.
Andreas! Thanks for reading and yeah, fair comment. This post is definitely skewed to more web/app developers than lower level coders. I'd wager there are more of those, I guess?
I'd put a low level language in the toolkit too, such as C or Rust.
Based on feedback from this post (originally written quite some time ago) I think I'll probably do a V2/revised with that added :)
Appreciate the comment!
I'm actually mostly working on data science in Python. But also not using any of these tools. It's not necessarily the language, though yes, system languages are also important.
But writing Python doesn't necessarily mean doing web stuff. You could do medical imaging or self-driving cars or weather forecast, and write Python and not use any of these technologies.
Of course! :)
Kinda echoing @amuellerml here, but I've been coding for many years, and I've only ever needed one of these (a scripting language) in my work. I'm a game and game engine developer, and I spent a lot of time creating libraries to that aim. You might consider re-titling. ;)
On that note, I think "full stack" is something of a misnomer as well. You're presumably doing web development, which is fantastic...but you aren't actually working with a huge part of the "stack" - the kernal, assembly, nor any of the low-level languages your technologies are built on. You're not messing with a GUI toolkit (you've got a pre-built web framework for that). Not to say you need to - it's pointless for your work - but it's still a legit part of the stack that coders actively work on. :)
Hey Jason,
Yeah, once again, fair comment. I probably should have defined full stack up front, as everyone kinda has a different definition in their head about it.
As I said here a revised edition will make more of an effort to consider game programmers too... which are almost in a different category! I'll think about how to make it work.
Keep crushing it! Gamers gotta game.
Well, there's a wide range among game programmers, too. Someone using Unity doesn't need the same tools as someone using PyGame, nor the same tools as someone (like me) building their own engine.
To be honest, there is very little all the branches of coding have in common. Probably an editor or IDE, a debugger, and a VCS. The rest varies.
If you'd like to know my company's complete stack, check out: mousepawmedia.com/developers/techn...
Thanks Jason! I'll take this into consideration for the next version of the post. I appreciate the insight here :)
Is be interested in reading more about this topic.
Curious about the same thing. My understanding is Kafka fits a queue more than a stream. Where Apache Storm would be more stream processing.
The difference, to me at least, is that Queue items are removed, where as stream items are observed.
RabbitMQ, for example, you remove from the queue and ACK them as you do so, whereas Kafka or Kinesis, you just observe, but keep a note of where you are in the read process.
Does that make sense? :)
It does! Thank you.
Great post. Solid advice. I'd add: a test framework and a mocking framework. (ex. jUnit/Mockito/Powermock.) Getting proficient with these tools and using them will help you get things done faster, and radically improve the quality of your output. And it helps your team watch each other's back. If there are tests for your code, nobody's going to accidentally break it, and vice versa.
Totally agree Chris, and I think my revised post will include a testing framework! (I've played with a few... I use RSpec daily, and have used many others, such as jUnit, Kiwi, KIF, XCTest and more!)
Thanks for bringing it up! Tests are SO important and I'm embarrassed I forgot them, if I'm honest haha.
Please pardon the little promotion here, but I actually wrote a testing framework, Goldilocks (part of PawLIB), for C++ that might work in scenarios where others might not. I wrote about it in the third part of this article.
Don't be embarrassed, Sam! This is a solid article. It seems to be aimed at Jr/mid-level web devs, but I've been doing this for 15 years, and I got plenty out of it. Cheers!
Really like this post, as a junior dev it's certainly got me thinking about how I'm expanding my toolbox. My one bit of feedback is when you mentioned Node.js as a Web Framework. Node.js isn't a web framework itself, but something like Express or Sails would be different web frameworks that node can use. In a similar vein, Laravel would be a web framework for PHP.
Thanks Max! Yup, fair correction. I guess I was thinking of Express at the time! :) I hope my point wasn't lost though.
I would add containerization/replicatable env tools - virtual box, vagrant, docker (swarm), kubernetes
after all, you are not running mysql and java and god-knows-what-else on your bare mac (or do you?))))
I use Docker for mac - thanks for the addition, I think it's valid! :)
Well... I agree with some of the thoughts stated in other comments (about this list being pretty much web-dev centric), and add some other point: I'm not convinced you need to be able to be into that bandwidth of technologies.
But I personally think you should have at hand some kind of tooling, workflow, framework set to give you the chance of building and running a basic application, and be it a prototype or a demonstrator. You should have a toolbox to get some business problem solved in code, and you should be able to get this code running on your future customers environment as fast as you can.
Hey Kristian, thanks for the comment!
Sure, you don't have to be into this many as above, but what works for me, to achieve what you're striving for above, is tasting a bit of every technology so I can get a feel of what the best solution might be when I come across my next problem :)
Great article Sam! I’m an infrastructure architect learning to code and this (along with the comments so far) provides me a with a great high level overview of what I should be looking at. I’m already working through a full stack course so it’s goid to know that I’m on the right tracks.
Nice Craig, I'm glad I could help :D
Why not throw any embedded systems programming skill in the mix? I mean, it's coding...
Point being, you don't actually need all these skills in your toolbox. Knowing what they are and where/why to use them, sure. But actually learning them all in a professional way takes a lot of time, and just using them in a single project doesn't always count.
More important than being a master of all trades, IMO, is being able to adapt to different environments. Going from front-end to back-end or vice versa shouldn't be a big hustle, but I don't expect a React.JS/Native developer to know anything about message brokers
(This is definitely an older post for me, so I've had some more thoughts since publishing)
I think the idea is that every good engineer should know what they dont know.
And, on the contrary, I think a frontend JS dev should know about message brokers, often used in delayed writes (conceptually), otherwise when they post back to the server, and the page refreshes, they might be very confused as to why the content doesn't reflect the recent addition! :D
Awesome post. I resonate with almost all of your suggestions. Apart from stream processing in kafka, I have been able to work with all the other mentioned technologies that you've mentioned. I am also an evangelist of developing a broad understanding of concepts. It helps the brain grow, according to me. Thanks for the post.
Thanks!