6 ms·

Many interests are pulling developers' attention in several different areas all the time. Database, security, accessibility, performance, infrastructure, tooli

Many interests are pulling developers' attention in several different areas all the time. Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things All of these like to say "if only the developer could do $MY_AREA better, they'd be better developers and we'd have better software". Each of them wants to pile on more requirements for what devs ought to know. Let's say we agree that devs should know all of these things. After you tally up every area's demand, you're probably looking at a 10 year timeline before someone's decent in all of these areas by spending approx. 1 year on each of these areas doing meaningful work (as opposed to contrived tutorials). Even then, things change constantly, so you'd have to continually practice all of these things. Who knows if we'll add a new category next year? Then it becomes an 11 year timeline. At some point, developer responsibility has to stop.

harikb 7y ago
Not really. That is exactly the point the article is trying to make. Developers need to care about these things - _enough to know who to go get help from_. That is the minimum. Also 10 years is an exaggeration. 2 years working on a non-trivial backend should expose one to these problems. From what I have seen, products built without caring about these will usually get rebuilt a year from the original release - either by the same company or by a competitor who killed them.
- mgkimsal 7y ago
  > 2 years working on a non-trivial backend should expose one to these problems. You can be exposed to them, but without understanding them, and experiencing both good, bad, and really bad 'solutions' to them, and understand the impact (on the business, on the code, on security, on maintainability, etc)... you just can't really get all that in 2 years. I know plenty of people who've been 'exposed' to certain type of tech problems, and the solutions they decide on are objectively really bad for any metric other than "stop this error from showing up on the screen right now". I've been doing this for a bit over 25 years, professionally now, and... there's a lot I don't 'get' with current stuff. But I've seen and lived enough projects, in enough different situations, to have a good idea of impact of tech decisions, and to understand how to make tradeoff decisions. I had someone call me up to 'fix' a problem in a system I'd given then 15 years earlier. It was still running, more or less the same, and... spelunking your own code 15 years later gives you a new perspective on the impact and value of decisions you make. Many of the things people get hung up on (code style, tabs/spaces/etc, particular naming conventions, etc) provide pretty much no value in digging in to old code that no one has touched or thought about in a decade. Correct comments, sample data, repeatable tests hold so much more value, but are harder to get people to commit to following through on.
  - bdamm 7y ago
    I wish I could slap anyone who gives a hoot about tabs vs spaces. Fortunately modern languages like go are removing the version control problem that not caring about style and using auto-formatting IDEs produces.
    - lowercased 7y ago
      I'm working in a couple of projects where there's a bunch of linter-checker things that prevent any PR merges (another... imo somewhat over-used tool) and... I split my time between Java, PHP, various SQL engines and various JS frameworks (react, extjs, vue, etc) and I'm constantly battling different mental models with various IDEs always showing different colored squiggles and highlights telling me all the ways I'm "wrong" about the code I've just typed. Can't use double quotes! Always to use double quotes! "Prefer string/template interpolation" in JS Always do string concatenation per another project's standards. Lots of different frameworks, languages, projects and companies all force different types of ceremony on formatting. "Hey, just let the tooling tell you!" turns in to constant UI distractions telling you that you're 'wrong' degrades (my?) performance. And... the value of most of these formatting things is pretty low, long term. I know that's heresy to some folks, and everyone I talk to sort of agrees, then says "yeah, but I really think standard XYZ is a good thing", but... it's nearly all preference, just like tabs/spaces.
      - yjftsjthsd-h 7y ago
        That sounds like bad tooling. Why not have every project use https://editorconfig.org/ https://editorconfig.org/ and then have your IDE auto-format? It shouldn't be popping up and making you fix it, it should fix it for you.
        lowercased 7y ago
        So there are tools that autoformat as you type? let longVariableName = "hello " + this.name; magically becomes const longVariableName = `hello ${this.name}`; without visually flagging it, just autocorrects as I type? And... I can just quickly swap settings for different clients? Because one has eslint block any PRs that don't have "prefer template" rules followed but another client doesn't like that style, and don't want that style in their code because it conflicts with existing style.
- deleted 7y ago
  [deleted]
- vsareto 7y ago
  >Not really. That is exactly the point the article is trying to make. Developers need to care about these things - _enough to know who to go get help from_. That isn't it. They aren't telling you to learn about database details for the sole purpose of "DBA handles databases. Go ask the DBA database questions". It's more than that. They're offloading specific knowledge onto the dev and then making them accountable for it. It's a reaction to common questions and an attempt to answer them all at once by teaching devs answers to common questions. This is a noble goal, but it's problematic in aggregate from multiple perspectives. The aggregate goal of all of these areas trying to teach developers their own specialties is to make developers the masters of low-hanging fruit.
hatchnyc 7y ago
I have done exactly this and found it to be a frustrating and thoroughly thankless exercise. No stakeholder for development teams care about any of this, and your allocation of shared resources plummets as people realize they can dump problems on your team and instead focus their attention on the ones who do not care.
AndrewKemendo 7y ago
10, 11 year timeline to what? You should be constantly learning everything about the whole stack so that you can actually build functional, reliable, manageable and maintainable systems. I expect a competent developer to be able to build a modern multi-page web application, with a HTML/JS front end, relational database back end, appropriately configured certificates and DNS/CNAME/URL, build basic uptime and application monitoring and do a basic SQL ETL data retrieval process. That seems like a reasonable bar, and while the specific tools have changed over the years, that stack is basically the same as it's been since the 90s.
- StandardFuture 7y ago
  You seem to be contradicting yourself without realizing it. > You should be constantly learning everything This is an in-progress action i.e. the developer is still learning. > I expect a competent developer to be able to build This is now considering a "learned" developer. I am not sure you are making the point you think you are making. The point I think you are trying to make is your expectations of what an experience developer should know. But, you seem to be expressing it as what a new developer should be doing. While the core discussion of the article might be in regards to what developers do and do not know, I can't help but notice that a developer knowing about something does not necessarily allow them to be productive in that area of their knowledge (especially relative to another co-worker with both the knowledge and the dedicated focus in that area). Also very important to note: the comment you are addressing seems to be referring to knowledge that is local (particular customer necessity/problems, particular architecture choices for infrastructure, particular product design decisions, particular ways to answer the quirky CEO/CTO in a way that they understand, etc.). There is a lot of locale-based knowledge that a developer must learn at a company/job/project and can even change over time (temporal-locales). Globally-applicable knowledge like frontend, backend, and general CS concepts are for sure a reasonable expectation of an experienced developer. But, there is a delicate balance a developer must take in the real working world that is subject to not attempting to master every aspect of the product/business (especially if it overlaps with someone else's job/focus) just because you have a high-level understanding of the global concepts. In other words, it is not necessarily efficient for a developer to know every aspect of every language and every database in the company unless that actually buys the company more customers and money. I would expect any decent manager to understand this very basic principle. Everyone in the company trying to be a master at everyone else's job does not help the company make more money. Being reasonable about expectations in the moment is also a critical asset of working together to make money. :)
throwaheyy 7y ago
Exactly. Without abstractions, developers would never be able to get anything done. Every task would be dozens of new rabbit holes.
- dcolkitt 7y ago
  The problem is that all abstractions are leaky in some way or another. If you're going to use an abstraction, you should at least learn enough about it to know where to put the buckets.
debaserab2 7y ago
I don't agree. If you're designing data structures in a code base you shoulder some of the responsibility for the persistence characteristics of that data. There's a lot of devs that think database design is the same as starting a new ORM class and generating a migration file. > Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things Yes, these are all things that devs should strive to know as much about as possible. Software isn't easy. It takes a long time to become an expert. 10 years sounds about right. > Who knows if we'll add a new category next year? Skill domains do come and go, but I think the ones you've listed are solid staples of web development for the past decade and likely will still be for a decade more.
- vsareto 7y ago
  > I don't agree. If you're designing data structures in a code base you shoulder some of the responsibility for the persistence characteristics of that data. There's usually not a relationship that goes the other way though, for example, developers don't tell DBAs to pick up code so they can write the models in our language in addition to the underlying SQL. This highlights a trend of increasing responsibilities pushed onto the developer. >Yes, these are all things that devs should strive to know as much about as possible. Software isn't easy. It takes a long time to become an expert. 10 years sounds about right. But in some cases it's specialists designating what an expert developer should know. It's giving away control in some respects. This turns into new job requirements and a higher barrier for entry. The growth will need to stop at some point.
  - AsyncAwait 7y ago
    Agree with this. There's the whole DevOps nowdays as well, which basically just shifts what used to be an entirely separate, full-time, role onto the developer. Adding DBA to that sounds like it would benefit noone, except perhaps business owners looking for short-term savings at the expense of productivity, ala open-office floor plans.
    - debaserab2 7y ago
jtdev 7y ago
> Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things Hammers, nails, tape measures, saws, levels, reading blueprints, adhesives... If you want to be a professional, you need to learn the tools of your trade. Being able to work directly with a SQL database is a foundational capability in the software development trade. ORMs are a mental crutch that are overused to the detriment of many systems.
- horsawlarway 7y ago
  Speed squares are a mental crutch that are overused to the detriment of many structures... Look, I actually agree with you about ORMs, but come on, this is a pretty bad take on the problem. The issue is rarely the tool itself, it's the changing requirements around how it's used. You can have the best hammer swing in the world, and maybe you sling the best tape ever. But if the building codes are revamped in non-trivial ways every 6 months, you're still going to want someone spending dedicated time understanding that. If your job is to assemble the stairs, you focus on that instead of wasting time asking why this blueprint happens to place the stairs at a slightly different angle, or why some places demand kiln dried timber vs simple construction grade. Your area of expertise is NOT the building code, it's integrating the stairs into the rest of the structure and actually having people walk up them.
- vsareto 7y ago
  >If you want to be a professional, you need to learn the tools of your trade. The tools of the trade has constantly been expanding. It's not set in stone as you imply. It's like me telling a carpenter that they now also must become an electrician, window installer, insulation installer, HVAC installer, steelworker, concrete worker, brick layer, and security system installer. Your new job title is "Fullstack Building Developer" instead of "Carpenter". We can't afford to have 10 specialists that all do a great job, we can only afford 1 person doing a poor/mediocre job in 10 things.

harikb 7y ago

Not really. That is exactly the point the article is trying to make. Developers need to care about these things - _enough to know who to go get help from_. That is the minimum. Also 10 years is an exaggeration. 2 years working on a non-trivial backend should expose one to these problems. From what I have seen, products built without caring about these will usually get rebuilt a year from the original release - either by the same company or by a competitor who killed them.

mgkimsal 7y ago
> 2 years working on a non-trivial backend should expose one to these problems. You can be exposed to them, but without understanding them, and experiencing both good, bad, and really bad 'solutions' to them, and understand the impact (on the business, on the code, on security, on maintainability, etc)... you just can't really get all that in 2 years. I know plenty of people who've been 'exposed' to certain type of tech problems, and the solutions they decide on are objectively really bad for any metric other than "stop this error from showing up on the screen right now". I've been doing this for a bit over 25 years, professionally now, and... there's a lot I don't 'get' with current stuff. But I've seen and lived enough projects, in enough different situations, to have a good idea of impact of tech decisions, and to understand how to make tradeoff decisions. I had someone call me up to 'fix' a problem in a system I'd given then 15 years earlier. It was still running, more or less the same, and... spelunking your own code 15 years later gives you a new perspective on the impact and value of decisions you make. Many of the things people get hung up on (code style, tabs/spaces/etc, particular naming conventions, etc) provide pretty much no value in digging in to old code that no one has touched or thought about in a decade. Correct comments, sample data, repeatable tests hold so much more value, but are harder to get people to commit to following through on.
- bdamm 7y ago
  I wish I could slap anyone who gives a hoot about tabs vs spaces. Fortunately modern languages like go are removing the version control problem that not caring about style and using auto-formatting IDEs produces.
  - lowercased 7y ago
    I'm working in a couple of projects where there's a bunch of linter-checker things that prevent any PR merges (another... imo somewhat over-used tool) and... I split my time between Java, PHP, various SQL engines and various JS frameworks (react, extjs, vue, etc) and I'm constantly battling different mental models with various IDEs always showing different colored squiggles and highlights telling me all the ways I'm "wrong" about the code I've just typed. Can't use double quotes! Always to use double quotes! "Prefer string/template interpolation" in JS Always do string concatenation per another project's standards. Lots of different frameworks, languages, projects and companies all force different types of ceremony on formatting. "Hey, just let the tooling tell you!" turns in to constant UI distractions telling you that you're 'wrong' degrades (my?) performance. And... the value of most of these formatting things is pretty low, long term. I know that's heresy to some folks, and everyone I talk to sort of agrees, then says "yeah, but I really think standard XYZ is a good thing", but... it's nearly all preference, just like tabs/spaces.
    - yjftsjthsd-h 7y ago
      That sounds like bad tooling. Why not have every project use https://editorconfig.org/ https://editorconfig.org/ and then have your IDE auto-format? It shouldn't be popping up and making you fix it, it should fix it for you.
      - lowercased 7y ago
        So there are tools that autoformat as you type? let longVariableName = "hello " + this.name; magically becomes const longVariableName = `hello ${this.name}`; without visually flagging it, just autocorrects as I type? And... I can just quickly swap settings for different clients? Because one has eslint block any PRs that don't have "prefer template" rules followed but another client doesn't like that style, and don't want that style in their code because it conflicts with existing style.
deleted 7y ago
[deleted]
vsareto 7y ago
>Not really. That is exactly the point the article is trying to make. Developers need to care about these things - _enough to know who to go get help from_. That isn't it. They aren't telling you to learn about database details for the sole purpose of "DBA handles databases. Go ask the DBA database questions". It's more than that. They're offloading specific knowledge onto the dev and then making them accountable for it. It's a reaction to common questions and an attempt to answer them all at once by teaching devs answers to common questions. This is a noble goal, but it's problematic in aggregate from multiple perspectives. The aggregate goal of all of these areas trying to teach developers their own specialties is to make developers the masters of low-hanging fruit.

hatchnyc 7y ago

I have done exactly this and found it to be a frustrating and thoroughly thankless exercise. No stakeholder for development teams care about any of this, and your allocation of shared resources plummets as people realize they can dump problems on your team and instead focus their attention on the ones who do not care.

AndrewKemendo 7y ago

10, 11 year timeline to what? You should be constantly learning everything about the whole stack so that you can actually build functional, reliable, manageable and maintainable systems. I expect a competent developer to be able to build a modern multi-page web application, with a HTML/JS front end, relational database back end, appropriately configured certificates and DNS/CNAME/URL, build basic uptime and application monitoring and do a basic SQL ETL data retrieval process. That seems like a reasonable bar, and while the specific tools have changed over the years, that stack is basically the same as it's been since the 90s.

StandardFuture 7y ago
You seem to be contradicting yourself without realizing it. > You should be constantly learning everything This is an in-progress action i.e. the developer is still learning. > I expect a competent developer to be able to build This is now considering a "learned" developer. I am not sure you are making the point you think you are making. The point I think you are trying to make is your expectations of what an experience developer should know. But, you seem to be expressing it as what a new developer should be doing. While the core discussion of the article might be in regards to what developers do and do not know, I can't help but notice that a developer knowing about something does not necessarily allow them to be productive in that area of their knowledge (especially relative to another co-worker with both the knowledge and the dedicated focus in that area). Also very important to note: the comment you are addressing seems to be referring to knowledge that is local (particular customer necessity/problems, particular architecture choices for infrastructure, particular product design decisions, particular ways to answer the quirky CEO/CTO in a way that they understand, etc.). There is a lot of locale-based knowledge that a developer must learn at a company/job/project and can even change over time (temporal-locales). Globally-applicable knowledge like frontend, backend, and general CS concepts are for sure a reasonable expectation of an experienced developer. But, there is a delicate balance a developer must take in the real working world that is subject to not attempting to master every aspect of the product/business (especially if it overlaps with someone else's job/focus) just because you have a high-level understanding of the global concepts. In other words, it is not necessarily efficient for a developer to know every aspect of every language and every database in the company unless that actually buys the company more customers and money. I would expect any decent manager to understand this very basic principle. Everyone in the company trying to be a master at everyone else's job does not help the company make more money. Being reasonable about expectations in the moment is also a critical asset of working together to make money. :)

throwaheyy 7y ago

Exactly. Without abstractions, developers would never be able to get anything done. Every task would be dozens of new rabbit holes.

dcolkitt 7y ago
The problem is that all abstractions are leaky in some way or another. If you're going to use an abstraction, you should at least learn enough about it to know where to put the buckets.

debaserab2 7y ago

I don't agree. If you're designing data structures in a code base you shoulder some of the responsibility for the persistence characteristics of that data. There's a lot of devs that think database design is the same as starting a new ORM class and generating a migration file. > Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things Yes, these are all things that devs should strive to know as much about as possible. Software isn't easy. It takes a long time to become an expert. 10 years sounds about right. > Who knows if we'll add a new category next year? Skill domains do come and go, but I think the ones you've listed are solid staples of web development for the past decade and likely will still be for a decade more.

vsareto 7y ago
> I don't agree. If you're designing data structures in a code base you shoulder some of the responsibility for the persistence characteristics of that data. There's usually not a relationship that goes the other way though, for example, developers don't tell DBAs to pick up code so they can write the models in our language in addition to the underlying SQL. This highlights a trend of increasing responsibilities pushed onto the developer. >Yes, these are all things that devs should strive to know as much about as possible. Software isn't easy. It takes a long time to become an expert. 10 years sounds about right. But in some cases it's specialists designating what an expert developer should know. It's giving away control in some respects. This turns into new job requirements and a higher barrier for entry. The growth will need to stop at some point.
- AsyncAwait 7y ago
  Agree with this. There's the whole DevOps nowdays as well, which basically just shifts what used to be an entirely separate, full-time, role onto the developer. Adding DBA to that sounds like it would benefit noone, except perhaps business owners looking for short-term savings at the expense of productivity, ala open-office floor plans.
  - debaserab2 7y ago

jtdev 7y ago

> Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things Hammers, nails, tape measures, saws, levels, reading blueprints, adhesives... If you want to be a professional, you need to learn the tools of your trade. Being able to work directly with a SQL database is a foundational capability in the software development trade. ORMs are a mental crutch that are overused to the detriment of many systems.

horsawlarway 7y ago
Speed squares are a mental crutch that are overused to the detriment of many structures... Look, I actually agree with you about ORMs, but come on, this is a pretty bad take on the problem. The issue is rarely the tool itself, it's the changing requirements around how it's used. You can have the best hammer swing in the world, and maybe you sling the best tape ever. But if the building codes are revamped in non-trivial ways every 6 months, you're still going to want someone spending dedicated time understanding that. If your job is to assemble the stairs, you focus on that instead of wasting time asking why this blueprint happens to place the stairs at a slightly different angle, or why some places demand kiln dried timber vs simple construction grade. Your area of expertise is NOT the building code, it's integrating the stairs into the rest of the structure and actually having people walk up them.
vsareto 7y ago
>If you want to be a professional, you need to learn the tools of your trade. The tools of the trade has constantly been expanding. It's not set in stone as you imply. It's like me telling a carpenter that they now also must become an electrician, window installer, insulation installer, HVAC installer, steelworker, concrete worker, brick layer, and security system installer. Your new job title is "Fullstack Building Developer" instead of "Carpenter". We can't afford to have 10 specialists that all do a great job, we can only afford 1 person doing a poor/mediocre job in 10 things.