4 ms·

The role of "Product Engineer" is a deeper solution to this issue that I find appealing. But let's do away with the term "engineer" almost completely, because

The role of "Product Engineer" is a deeper solution to this issue that I find appealing. But let's do away with the term "engineer" almost completely, because what the average web application developer is doing is hardly engineering. The tools are at the point where most of the computer engineering has been abstracted away to the point where developers can primarily focus on business logic. Most experienced web application developers that I know have already been doing product work in their day-to-day routines. People who actually write code in direct contact with customers and their needs is highly efficient. Our industry needs an order of magnitude less people who do not write code. In my view everyone should be a programmer of some sort. Our management tools are programmable yet management will not lower themselves to the ranks of the manual laborer and instead will choose to hire someone to program their management tools for them. This is highly inefficient. I'm sure we would see less meetings if management actually had something worthwhile to do with their time. I do see a need for computer engineers in that they should write the tools that the other programmers use for these kind of domain-specific purposes.

williamcotton 4y ago
This should in turn reduce not only the layers of management but the need for managers to make up for the inefficiencies between "person dictating idea" and "person implementing idea". It's also a sign to me that our tools for product development are too general purpose and we would benefit from less capable and easier to learn and use DSLs. Those DSLs should at least be extendable from in-house computer engineers who do in fact worry about things like data storage, CPUs, and memory management.
agomez314 4y ago
Great insight. Like Hal Abelson said, nowadays it's more of a matter of how "you use various kinds of programming styles and techniques like combinators to glue things together." This lowers the bar to programming to more people, making the excuse "i'm not technical" less and less relevant.
93po 4y ago
You may have had the pleasure of working at places where developers are very self-directing and don't need constant hand holding. As an engineer (developer) of more than a decade that has since transitioned to product, my experience is that developers (again, just in my experiences) at places I've worked are entirely are completely incapable of knowing what to build. They don't ask the right questions and they don't understand the business needs well enough to know the right solutions. They get stuck at the smallest hurdles and I have to guide them over each and every one of them, even when it's 98% a technical problem (which legacy database should this application be populating? I don't know, let's ask the PM instead of consulting technical documentation or running our own profiling to determine this). They don't want to make decisions around anything at all. Managing questions and making decisions for a team of 6 is easily a full time job for me combined with client management and meetings. I work a lot of extra hours to do actual PM work on top of that. I realize this is also largely my organization's fault for not having a dedicated project manager, but that's still not really helping me see your argument about needing fewer non-coders.
- williamcotton 4y ago
  What if instead of you and a team of six developers there were just yourself and one other who did all of the development as well as product work? And what if the tools you were using for development and even the language itself were geared specifically for your domain? What if you have computer engineers who worked on the language and tools so you could focus as much on the customers and the product? People use Google Sheets without having to know anything about how Google Sheets is written or deployed! My theory is that a lot of management is there in an attempt to make up for all of the organizational inefficiencies and that meetings are mainly there to make up for inefficiencies in communication because of the divide between the "what" and "how" at the same level of abstraction. I'm perfectly fine with top-level management keeping all of their programming confined to a spreadsheet but even there I see room for improvements to their tooling!

williamcotton 4y ago

This should in turn reduce not only the layers of management but the need for managers to make up for the inefficiencies between "person dictating idea" and "person implementing idea". It's also a sign to me that our tools for product development are too general purpose and we would benefit from less capable and easier to learn and use DSLs. Those DSLs should at least be extendable from in-house computer engineers who do in fact worry about things like data storage, CPUs, and memory management.

agomez314 4y ago

Great insight. Like Hal Abelson said, nowadays it's more of a matter of how "you use various kinds of programming styles and techniques like combinators to glue things together." This lowers the bar to programming to more people, making the excuse "i'm not technical" less and less relevant.

93po 4y ago

You may have had the pleasure of working at places where developers are very self-directing and don't need constant hand holding. As an engineer (developer) of more than a decade that has since transitioned to product, my experience is that developers (again, just in my experiences) at places I've worked are entirely are completely incapable of knowing what to build. They don't ask the right questions and they don't understand the business needs well enough to know the right solutions. They get stuck at the smallest hurdles and I have to guide them over each and every one of them, even when it's 98% a technical problem (which legacy database should this application be populating? I don't know, let's ask the PM instead of consulting technical documentation or running our own profiling to determine this). They don't want to make decisions around anything at all. Managing questions and making decisions for a team of 6 is easily a full time job for me combined with client management and meetings. I work a lot of extra hours to do actual PM work on top of that. I realize this is also largely my organization's fault for not having a dedicated project manager, but that's still not really helping me see your argument about needing fewer non-coders.

williamcotton 4y ago
What if instead of you and a team of six developers there were just yourself and one other who did all of the development as well as product work? And what if the tools you were using for development and even the language itself were geared specifically for your domain? What if you have computer engineers who worked on the language and tools so you could focus as much on the customers and the product? People use Google Sheets without having to know anything about how Google Sheets is written or deployed! My theory is that a lot of management is there in an attempt to make up for all of the organizational inefficiencies and that meetings are mainly there to make up for inefficiencies in communication because of the divide between the "what" and "how" at the same level of abstraction. I'm perfectly fine with top-level management keeping all of their programming confined to a spreadsheet but even there I see room for improvements to their tooling!