What every developer should know – Ultimate Edition

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!

 

Starting point

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…”

• databases
• your current database like SQL Server
• your potential next database like MongoDB
• containers
• specific container
• cloud
• specific cloud technology/provider
• soft skills
• specifically communication
• and more specifically communication for a technical team leader
• HTTP(S)
• URLs
• logging
• performance
• performance with your back-end language
• web development performance
• front-end specific technology performance
• SQL performance
• specific database system performance
• measuring performance
• interviewing
• problem solving
• low level programming
• methodologies
• specifically Agile / Kanban
• and on technical side TDD
• 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. front-end) this year
• hot new tech and changes in your field (e.g. front-end) delivered in a weekly newsletter, with a list of topics that would consume you for two weeks

Let’s choose 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

Be sure when you say you know something!
If there is any new feature in the new IDE version, new language version, new quirk, new concept, you better know it.
You will 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.
If you had put a technology in your resume, it means you are an expert with it.

 

Carrer paths

If you read a book “Programming X with C#”, finish a course on Udemy, complete a bootcamp, you are Book-X-C#-developer or Udemy-Course-1773-JavaScript-developer, University-Y-Graduate-of-2002 – as you got knowledge, tools, practices and perspective from that source(s) only.

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 and projects, where developers were familiar only with basics of the tool or language.

• Javascript Replace() replaces only the first instance of a value in a string, loop, global modifier or regular expression is required
• Javascript equality rules observation, funny story, or bug caused by it
• 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

With conscious effort, acceptance that developers do not know everything, developers change companies, that kind of examples can make a company grow.

If certain gaps are observed over and over in newly joined developer’s knowledge, by multiple tech leaders in a company, that exact gaps 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.
That part is commonly used during technical interviews.
Also important knowledge, but not for actual position the company put an offer. Good analogy can be “You should know how it works under the hood, how to construct it from parts, even if your job is to clean the screen of this machine”.

• 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()
• 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 strict-budget-limited maintenance (bugfixing) of an old VB.NET application created with a database-first approach (so classes would be a 10k lines giants only used as data mappers for the “view” part)

That way companies instead of focusing on “basic knowledge” but checked with utmost detail, prefer to positively validate overqualified engineer that will overenginner the solution, and make simple mistakes in the “basic” part.

 
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. They may appear very simple, but can turn out to require Ops specialist or certain technology specialist.

Those elements will appear often, take too much of your time and make the project late, and often you will not learn much as they will not repeat in another project / company.

• 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
• Using version X of MsBuild on the build server, know which 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 as a C# developer
• Analyze WinForms images processing performance or WinForms memory leaks
• Use a scripting language for a simple script (and make it fail due to wrongly placed space – spaces are not allowed in batch files as comments; some languages use indentation instead of brackets)
• 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

 
Other
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.

An example for a roadmap can be a “Technology Radar”, like FP Tech Radar 2020 published by the Future Processing company.

 

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.

Discussion on hacker news
Discussion on Reddit
One of response posts

On the 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.

There is an opinion that technology put in a resume / LinkedIn profile mean that person is an expert in it – otherwise it should not be mentioned. “Either you know it or don’t”. And it includes all versions of a technology/tool unless the version you “know” is specified.
I have seen that opinion present during various online discussions between developers.

 

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…”

At the start, looking at headlines and keywords is enough. If one topic is seen most often with any of the filters (e.g. tool on popular SQL blog, JavaScript library on most of the job offers in the area), then it may be good to know more about it.

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 can be presented on the 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 do not need to specialize in coding and trivia quizes – I will let my portfolio speak

 
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.

Pre-learning a solution to many very specific problems will allow to solve probably 3 of 100 problems on the spot, instead of 1 of 100 if you have just used your intuition.

 
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.