7 ms·

So, it seems like the pendulum is swinging back. I remember companies with more dedicated specialists, and it could be challenging to ship small features due to

So, it seems like the pendulum is swinging back. I remember companies with more dedicated specialists, and it could be challenging to ship small features due to large coordination efforts. Further, sometimes the work is unbalanced. In my current company, we recently had a backend-dominant release in a way that the frontend team didn't have as much work. That team rolled up its sleeves and dug in to solve problems, even if they weren't specialized in it. They weren't happy. It wasn't what gave them joy, but it was what was necessary for everyone to release what was needed. Now, we made sure that they had access to backend developers who could pair or guide work, and we knew the work would talk longer. (After all, these were developers who were stronger in the front end!) With our next release, we look to be more balanced, but we're looking at having developers with more backend competencies contribute to the frontend this release. I think it's too much to ask for developers to be equally brilliant in multiple areas, but I don't think it's too much to ask that people have the willingness to develop minimal proficiencies in multiple layers and the willingness to contribute and learn.

mntmoss 7y ago
I think the broad historical sweep here is sort of along the lines of: * From the early microcomputer era onwards, applications development focused on getting developers that knew the base platform or operating system(e.g. if you knew "Win32" dev, that was solid in the mid-90's) - and it was one platform per category of application, and for applications that integrated a database you also had platforms like Foxpro, Access, or Hypercard. Specialization beyond that was typically the domain of big-iron computing, which had an older market and talent pool that was used to a certain model and infrastructure of scaling to solve the data processing needs of the era. * Increased usage of computer networking pushed all development towards a multi-tier setup(e.g. LAMP stack or the multifarious forms of Java and .Net), meaning that more applications needed "front-end" vs "back-end" division, regardless of their needs. We addressed the problem at a local level by gluing together big-iron concepts and microcomputer concepts to get an awkward-yet-servicable jumble of domain competence, with the Web as the dominant frontend. A very small number of Internet companies pushed the boundaries and set the standards on data processing and frontends, and the market followed in their footsteps and used their leftovers. * Now that we have built out a lot of leverage towards all the possible speciality roles and computing is firmly in the hands of a few giants that can leverage all of that specialization, commoditization is creeping in and pushing smaller development teams back into more consolidated platforms. "The browser is the OS" is effectively true today, except that it's a terrible OS, scarred by numerous wars to control the platform and enable only specific categories of applications. What developers are moving towards, but are having trouble reaching because of the sheer number of established layers and protocols and required features, is another Hypercard that consolidates concepts into a single consumable, more uniform package, without requiring you to know all the boundaries and sharp edges that exist when going between the JS type system, the SQL engine, the browser engine, serialization protocols, network conditions and hardware status, etc. This is not a project that can be accomplished by lightly papering over the existing systems with framework glue - it requires attention to detail to clean up and simplify each part of the whole. So it takes time. But at the same time, I think we're also going to get where we want to go, faster than we think. The introduction of, and adoption of Web Assembly, is a major milestone because it raises the level of local processing and hence local platform consolidation, which in turn limits browser-specific APIs to importance in terms of their core I/O functionality, and not one-off standardized features. New platforms can carve out more and more space from that starting point, ultimately resulting in applications that have replaced the browser with a custom native runtime, but still ship WASM binaries. Simultaneously, native code development is getting better. The bottom of the stack is getting attention after leaning heavily on the traditional C/Unix model for decades and accumulating features without major revision - Rust and systemd are two healthy(if polarizing) examples. And at that point, the classical Open Web is dead, but it's due to be replaced in turn with a second coming of specialized, decentralized and federated protocols - new takes on Usenet, IRC, FTP, etc. The wheel will keep turning, though all the formats might churn.
- ebiester 7y ago
  I think there's truth to that when looking at internal software, but external (B2C) software will continue to live in this division. (Think of hotels.com as an application, for example. There's no world where you can build a hypercard app that meets those needs.)
chx 7y ago
> Further, sometimes the work is unbalanced My team has just grown my two backend developers to three. We also have six frontenders. Yes, the work is unbalanced, hire for it.
- ebiester 7y ago
  Last release, I was unbalanced on the back end. This release is different. The work changes. Do I lay people off and rehire each quarter based on business need? (No.) do I tell business we can’t do more valuable work while less valuable work is happening? I have a budget as a manager. I can’t always just hire more.
  - sanderjd 7y ago
    My two cents: you don't need "full stack developers", but you also don't want "front end developers" and "back end developers". You want people who can play either role (and many more) as needed, but with training friction in between.
    - ebiester 7y ago
      I think of it as T-shaped developers who have the attitude that they can learn what is necessary, have a culture of collaboration that reduces the friction of learning, and still allow people the ability to shine in code. I think of my teams as "primarily front end" and "primarily API/back end." Many people would call that "full stack." Some would call a developer like me "full stack" as in my career I've been a backup sysadmin, Db (pl/sql) dev, back end, front end, and a few other things as needed. But at any one time, I can really only be proficient in two of these - everything else decays.
  - marcus_holmes 7y ago
    Can you stream multiple releases in parallel instead of doing them in series? E.g. release A has 75% back-end, release B has 75% front-end. You can have front-end devs finish their work on release A and then start on release B before release A is out. (Though, obviously, not that simple. You'll need at least one front-end dev to stay on release A to solve integration issues, and you'll probably need a back-end dev to create endpoints, etc, on release B. But the principle holds, still). It's more efficient to keep everyone working at their fastest, most productive (and enjoyable) tasks whenever possible. But it does take more (and better) management to handle it.

mntmoss 7y ago

I think the broad historical sweep here is sort of along the lines of: * From the early microcomputer era onwards, applications development focused on getting developers that knew the base platform or operating system(e.g. if you knew "Win32" dev, that was solid in the mid-90's) - and it was one platform per category of application, and for applications that integrated a database you also had platforms like Foxpro, Access, or Hypercard. Specialization beyond that was typically the domain of big-iron computing, which had an older market and talent pool that was used to a certain model and infrastructure of scaling to solve the data processing needs of the era. * Increased usage of computer networking pushed all development towards a multi-tier setup(e.g. LAMP stack or the multifarious forms of Java and .Net), meaning that more applications needed "front-end" vs "back-end" division, regardless of their needs. We addressed the problem at a local level by gluing together big-iron concepts and microcomputer concepts to get an awkward-yet-servicable jumble of domain competence, with the Web as the dominant frontend. A very small number of Internet companies pushed the boundaries and set the standards on data processing and frontends, and the market followed in their footsteps and used their leftovers. * Now that we have built out a lot of leverage towards all the possible speciality roles and computing is firmly in the hands of a few giants that can leverage all of that specialization, commoditization is creeping in and pushing smaller development teams back into more consolidated platforms. "The browser is the OS" is effectively true today, except that it's a terrible OS, scarred by numerous wars to control the platform and enable only specific categories of applications. What developers are moving towards, but are having trouble reaching because of the sheer number of established layers and protocols and required features, is another Hypercard that consolidates concepts into a single consumable, more uniform package, without requiring you to know all the boundaries and sharp edges that exist when going between the JS type system, the SQL engine, the browser engine, serialization protocols, network conditions and hardware status, etc. This is not a project that can be accomplished by lightly papering over the existing systems with framework glue - it requires attention to detail to clean up and simplify each part of the whole. So it takes time. But at the same time, I think we're also going to get where we want to go, faster than we think. The introduction of, and adoption of Web Assembly, is a major milestone because it raises the level of local processing and hence local platform consolidation, which in turn limits browser-specific APIs to importance in terms of their core I/O functionality, and not one-off standardized features. New platforms can carve out more and more space from that starting point, ultimately resulting in applications that have replaced the browser with a custom native runtime, but still ship WASM binaries. Simultaneously, native code development is getting better. The bottom of the stack is getting attention after leaning heavily on the traditional C/Unix model for decades and accumulating features without major revision - Rust and systemd are two healthy(if polarizing) examples. And at that point, the classical Open Web is dead, but it's due to be replaced in turn with a second coming of specialized, decentralized and federated protocols - new takes on Usenet, IRC, FTP, etc. The wheel will keep turning, though all the formats might churn.

ebiester 7y ago
I think there's truth to that when looking at internal software, but external (B2C) software will continue to live in this division. (Think of hotels.com as an application, for example. There's no world where you can build a hypercard app that meets those needs.)

chx 7y ago

> Further, sometimes the work is unbalanced My team has just grown my two backend developers to three. We also have six frontenders. Yes, the work is unbalanced, hire for it.

ebiester 7y ago
Last release, I was unbalanced on the back end. This release is different. The work changes. Do I lay people off and rehire each quarter based on business need? (No.) do I tell business we can’t do more valuable work while less valuable work is happening? I have a budget as a manager. I can’t always just hire more.
- sanderjd 7y ago
  My two cents: you don't need "full stack developers", but you also don't want "front end developers" and "back end developers". You want people who can play either role (and many more) as needed, but with training friction in between.
  - ebiester 7y ago
    I think of it as T-shaped developers who have the attitude that they can learn what is necessary, have a culture of collaboration that reduces the friction of learning, and still allow people the ability to shine in code. I think of my teams as "primarily front end" and "primarily API/back end." Many people would call that "full stack." Some would call a developer like me "full stack" as in my career I've been a backup sysadmin, Db (pl/sql) dev, back end, front end, and a few other things as needed. But at any one time, I can really only be proficient in two of these - everything else decays.
- marcus_holmes 7y ago
  Can you stream multiple releases in parallel instead of doing them in series? E.g. release A has 75% back-end, release B has 75% front-end. You can have front-end devs finish their work on release A and then start on release B before release A is out. (Though, obviously, not that simple. You'll need at least one front-end dev to stay on release A to solve integration issues, and you'll probably need a back-end dev to create endpoints, etc, on release B. But the principle holds, still). It's more efficient to keep everyone working at their fastest, most productive (and enjoyable) tasks whenever possible. But it does take more (and better) management to handle it.