There are many articles regarding essential knowledge for software developers but with this one, you won’t need any other, here comes the ultimate list!
You may have read materials like
- What .NET Developers ought to know to start in 2017 by Scott Hanselman
- Programmer Competency Matrix by Sijin Joseph
- Full-stack compedium by Joe Honton
- Full-stack in 2020 by Colby Fayock
- The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) by Joel Spolsky
- 97 Things Every Programmer Should Know: Collective Wisdom from the Experts
- 10 Things Every Programmer Should Know by Javin Paul
- 50 tips for improving your software development game by Mitch Pronschinske
- Every Programmer Should Know by Alexey Migutsky
- 6 GitHub Repos For Instant Knowledge Boost by Miroslaw Farajewicz
And there is more.
This post title gave around 700 000 000 results in Google when I have started writting it. Probably hundreds of new articles coming out each day.
Knowledge structure and definition
When getting into one of the topics from the lists, let’s say security, it quickly becomes clear that the knowledge is not packed in one article or one book, but it spreads like a tree, with many subtopics and new concepts, new concepts and new definitions in those new concepts, etc.
With the tree structure, we get articles like “What developers should know about…”
- your current database like SQL Server
- your potential next database like MongoDB
- specific container
- specific cloud technology/provider
- soft skills
- specifically communication
- and more specifically communication in a team leadership
- performance with your back-end language
- web development performance
- front-end specific technology performance
- SQL performance
- specific database system performance
- measuring performance
- problem solving
- low level programming
- specifically Agile / Kanban
- and on technical side TDD / DDD
- system analysis e.g. event storming
- project management, estimation
- software testing (QA)
- architecture patterns like CQRS
- specific technology like RabbitMQ
- documentation creation
- operating systems
- group of operating systems
- specific operating system
- specific version of an operating system
- tools, editors, IDE
- specific IDE
- specific version of the IDE
- hot new tech in current year
- hot new tech and changes in your field (e.g. frontend) this year
- hot new tech and changes in your field (e.g. frontend) delivered in a weekly newsletter, with a list of topics that would consume you for two weeks
Okay, we have chosen a topic we think we know.
To say “I know X” one should be able to use that knowledge on the technical interview, partially understand experts in that area, and give a presentation / teach the concept to the junior developer. Then we can say that area of knowledge is understood.
The real programmer and the impostor
If there is any new feature in the new IDE version, new language version, new quirk, new concept, you better know it.
You never know if would be needed for your pet project, on the job when production crashes, a colleague may ask “Did you know…”, or on a job interview.
And if you don’t know that one thing at that moment, you are a fraud. Someone else clearly knew!
Real programmers would know that.
Computer science course on an University will surely change after couple of years.
Even certificates are limited to some area of knowledge and are outdated soon (tied to certain version).
Conferences are usually very generic and very specific same time.
What developer should really know then
Accurate knowledge levels
Maybe if we classify knowledge better than “required knowledge” and “next time you better remember it”, it would be easier to work with knowledge.
Knowledge management can be useful for programmers (I know this that much so I can estimate the feature) and employers (this developer knows that area that much so we can give him this project). With an “all or nothing” approach it is not possible to make informed decisions and move forward.
I would group Software development knowledge based on usefulness for the actual job/project, into categories:
Basic knowledge for particular topic
That kind of knowledge assures that a developer e.g. run an IDE of choice at least once and wrote the code, or has a general idea about a broad technical topic. It is almost sure that knowledge would be used in the current job (especially if that IDE and language are used).
- I can open Visual Studio and create example WinForms application to show a messagebox
- I can change text color of all H1 headers using CSS
- I can join two tables in SQL
- I can describe how the Git process works (checkout, pull, commit, push, merge)
- I can write code and tests for the FizzBuzz application
- I can describe what is indexing in databases, its advantages, and disadvantages
- I can describe what asynchronous means with a non-technical example
- I can change an existing IIS web application to use a static HTML file instead of its current flow
Tricky but useful
Something not obvious but must come after an experience with a particular technology or tool. Sooner or later a developer would have to deal with the problem.
Of course, sometimes the processes in a company may prevent a developer from exploring these himself, on the other hand, figuring out why a certain process is in place is a sign of curiosity.
Examples below are knowledge gaps I have seen across companies, projects and developers, familiar only with basics of the tool or language.
- SQL Server Management Studio query tabs being active connections, and choosing “Disconnect” on the left panel does not break the connection
- T-SQL Raiseerror behaviour being different depending on a severity “magic number”
- T-SQL select * top(1) returning random row
- T-SQL comparison to null should be done with “is” and not “=”
- IIS Express for Visual Studio is 32-bit by default, certain option needs to be checked in VS for 64-bit
- IIS web.config file is overwritten in the IIS UI
- First request to IIS can be slow due to pool default configuration and no warmup calls, but there may be many other reasons before this one is checked
With conscious effort, acceptance that developers do not know everything, developers change companies, that kind of examples can make a company grow.
If those issues are observed in newly joined developers by multiple tech leaders in a company, that exact issues could be interview questions or discussion points, and same time implemented procedures, checks, guides, or training for future developers to not make the same mistakes.
Trivia and academics
Knowledge from school, books, easy to copy from Google, and easy to verify for even non-technical persons.
That kind of knowledge is rarely useful in actual projects, or can be found in documentation in a matter of seconds.
In that group lies also the very theoretical knowledge.
- Difference between statically and dynamically typed languages, while it is something different than strongly typed and weakly typed, so is not so easy as we think, according to this StackOverflow discussion
- Memory management advanced topics in .NET, when current application company develops needs a full-stack for an internal tool mostly dealing with front-end
- What is correct to write output: System.WriteLine() or System.Environment.Write() or System.Console.Write(), while company has only APIs and no console applications
- Write code from scratch to connect to the database using ADO.NET, when current project uses Entity Framework
- Explain binary search tree complexity, when you will be developing ASP.NET SPA application that gets data from web services and pushes it forward without much business logic
- Implement Fibonacci algorithm, while clients are from healthcare and not from education industry
- Explain dynamic keyword in C#, when you will not work with Word or Excel documents
- Explain volatile keyword in C#, while your application is a single-thread app, also not interacting with any hardware directly
- Describe OSI model, when your job would be changing UI of a WinForms application working with locally stored images
- Describe five design patterns, but your job would be a maintenance of an old VB.NET application created with a database-first approach
Once in a lifetime, company specific
That category is related to projects and companies. Working on certain versions of tools and languages often means dealing with their limitations. Same with certain software development processes and environments.
You won’t even know that you do not know these things, or how complicated they are. Many of them may be related to DevOps, but as I have said, they may appear very simple.
- Create synchronized chained promises in AngularJS
- Try to validate SQL code that is saved as string into the database text column
- Configure clean Windows installation (including firewalls) on a server to use WebPublish from client workstations
- Install and configure Jenkins/JIRA/Bitbucket from scratch
- Choose the best Azure plan for client of your application
- Fix the broken certificate chain on a server after uploading new certificate from the provider
- We are using version X of MsBuild on the build server so you need to know which certain C# keywords to not use to make the build pass
- Change resolution of the VirtualBox VM to the higher value than your host provides
- Try to automate most of the installer and documentation steps using Powershell
- Analyze SQL queries using Execution Plan to find the bottleneck
- Use Wireshark and Fiddler to determine why your .NET application first request is slow. Is it network, client, server?
- Use Source Tree / Visual Studio instead of command line for all of the needed Git operations
- Follow some exotic protocol / web service standard that has been agreed with other parties
All other knowledge is rather close to any of the groups above.
Solution #1 – filter
What to do with all of that possible knowledge? How to prioritize?
I would suggest adopting one or couple filters from:
- what is related to my specialization
- what is fun and interesting
- what will get me promoted / employed / bring more clients
That way we add some purpose and motivation to the knowledge gaining process and at the same time filtering it. It is just impossible to survive without a filter or a plan.
Solution #2 – buy an encyclopedia
I am old enough to remember the times where for a programming job I would use physical books. An employer had a shelf with books and for some advanced topic, I would use a book as a reference.
When I see a doctor, an architect, or a lawyer checking a reference using a book, it looks professional – they are double-checking their knowledge. It does not look “they do not know how to do their job”.
It also looks really impressive to see a big shelf of books – “Wow, that specialist must know references to all these books to search for an answer when needed”.
Now, when a developer asked about something says “let me Google that for a minute”, his project manager would immediately think “My little grandson could do that too”.
Solution #3 – accept limitations
It is physically not possible to know everything, even if you knew something 10 years ago, that knowledge won’t be so fresh right now.
Developers should be able to estimate the problem due to its difficulty, and not be afraid of saying
I have not faced that problem before, I will look for potential solutions, analyze them, and come back to you.
I need to double-check if that would work.
Yes, I know that tool, but the last time I have used it, it took one day but that was three years ago.
However, admitting to not knowing everything is still seen as something brave.
Dan Abramov is co-author of Redux, and now he works on React.
His confession Things I Don’t Know as of 2018 started a discussion around essential knowledge programmer must-have.
On one hand, many developers agreed that software engineer does not have to know everything, on the other hand, the developer should try as hard as possible, or compensate it with an exceptional specialization.
Regular developers in regular companies would be rather afraid to post their list of gaps in the knowledge.
Solution #4 – perspective
We are experts in a certain technology or work with it daily, so it is easy for us to post “What developer should know about X”.
It is difficult to say something is not easy after doing it for years.
It is easy to criticize.
Unfortunately, when doing a certain thing over and over in the current company, one may assume it is “Basic knowledge”.
It is the same with “books true fantasy fan should read”, “metal albums true fan has to know and will be examined before every concert”, “board games you need to learn before even thinking you like board games” and so on.
All come from a perspective of a single individual, a group of individuals with the same experiences (e.g. same tech stack in a company), or from an article written by another single individual.
When being judged and judging, remember about the perspective. It is so natural to think “How did you not try to use X”, and I have caught myself multiple times thinking that way when seeing a developer fighting a long battle with an easy issue.
Then, the logical reasoning a few moments after was “Oh you use that tool occasionally and probably not had a longer task to get more familiar with it”.
An example of a perspective approach to technology is an article My Perfect 2020 Stack: A New Stack for a New Generation by Joe Honton.
Solution #5 – take action
Subscribe to some newsletters, podcasts or browse blog topics like “What dev should know…”
To make the knowledge more permanent, it would be best to summarize what has been learned, save some code drafts and snipets, configurations, even blog about it. Having a technology “checked” can be beneficial for:
- deciding that new technology I can present on my resume
- having a list of self-improvements for a raise / yearly review
- having a learning path prepared for someone junior in my specialization
- a weapon against an impostor syndrome
Solution #6 – but with patience
The action approach should not fuel the impostor syndrome, the change in how one would look at knowledge is needed.
From an examination approach:
I need to know X before I would be asked about it – otherwise I would be recognized as a fraud
to the purpose approach:
It is useful for my project
It is generally enjoyable
That one thing is not useful for me now and I will ignore it
Oh that is just some trivia I do not need
Today I do not want to write code in the evening
I know Y but not Z and that is fine
I would boldly say that it is better to read one short article a week that is relevant and enjoyable than study a long and difficult book every month because “you have to”. Because the book is on the list of someone’s article of best programming books and you feel like to have to read those books one by one.
And remember that besides the possibility of knowing all keywords of your current language, there are many skills you already have. You do not need to spend months on something new just because it is new. Be confident with what you know, have built, and experienced.
On these ending words, I would recommend reading a story from Zain Rizvi titled The Impostor’s Advantage.