robespierre wrote:Is there any specific theory that you can rely on a developer to know? I'm having trouble thinking of any. Extreme or Scrum are not theories in this sense. It's the difference between "a craft" and "a discipline".
Right, I would classify Extreme or Scrum as project management methodologies rather than technical expertise. Certainly good to be familiar with as they have direct application to the field, but not quite in the same domain as technical knowledge.
Unfortunately your vocabulary was very well chosen! There is much I would expect
someone to know, as a professional developer, but not much I can rely
on them knowing. This is very different from traditional science and engineering fields, where a Masters or Doctorate degree in a scientific field implies a working familiarity with that field's theory and research. Likewise a Professional Engineering certification
, in an engineering field, indicates not only standards tested competency in both theory and practice, but also an ongoing commitment to continuing education in their field's advancements. Even craft-practicing tradespeople are still held to standards and best practices (e.g. the National Electrical Code).
Those are the standards people get held to when designing roads, aircraft, datacenters, or even computer chips, but unfortunately software is a much different matter. Instead of "this is how you design a bridge according to mechanical engineering principles and known industry best practices," your average software programmer would say something like: "well, I copied and pasted parts of a few different bridge designs off of tutorial websites and StackExchange for NodeBridge 0.1 alpha, which is what everyone is using, and it ran and passed QA, so let's ship it."
I mean, I would idealistically expect
mid-level to lead developers to know and apply things like:
- Basic datastructures (lists / queues, trees, graphs)
- Algorithmic efficiency (linear vs. exponential time, etc.)
- Space vs. time tradeoff principles
- A basic understanding of the different types of languages, imperitive, declarative and procedural
- Features and conventions of the language they are operating in
- Debugging and profiling tools for their language
- Object oriented programming principles and design patterns (e.g. SOLID principles)
- A top to bottom understanding of the abstractions that they use (i.e. being able to at least roughly visualize their code's execution in machine language)
- Basic concurrency and parallelization techniques (threading and thread related data structures, inter-process communication, shared memory vs. mailboxing/messaging, statelessness, divisible workloads)
- Different types of datastores and tradeoffs (relational, document, key/value, etc.)
- A basic understanding of IP and friends (TCP, UDP, ICMP), routing, and sockets
- The advancing state of their language's ecosystem, in terms of frameworks, etc.
- Common application architecture and service design patterns
- Automated testing (e.g. unit tests, mocking, automated UI and acceptance testing frameworks, performance testing suites, etc.)
- Best practices for documenting their work, from source code to APIs and application architecture
For someone that makes near or at six figures, I think it's only responsible to meet similar standards to other engineering professionals.
But to your point, it is always hard to say what any one person actually does know. So many people these days get by just plugging together lego blocks until something turns on. I'm not really advocating for having some sort of professional standards organization for software developers, despite the effect that has had on other fields. I think that would be a bit heavy handed. On the other hand, I can't say I'm happy with the results today either.