6 ms·

BTW: The linked article is from 2009. My experience differs from the article. Where I have been and worked, if someone just copies together stuff they found on

by fefe23 4y ago

BTW: The linked article is from 2009. My experience differs from the article. Where I have been and worked, if someone just copies together stuff they found on stackoverflow, that's not considered productive programming. That's usually a sign of incompetence. Also, pulling in huge frameworks to solve some simple acute problem is also not considered productive programming. It may solve the problem at hand (poorly, usually) but it will create huge future costs for maintaining the dependencies, applying patches, and following changes. In my world, productive programming means solving an actual problem quickly and effectively, and in a way that minimized legacy costs in the following years. The code you leave behind is easy to follow, has few side effects or even none, is not just correct but obviously correct. And where it is not correct, it is easy to fix. You leave behind code that has documentation and good unit test coverage. Code that you needn't worry about. THAT is productive programming in my world. That said, I have personally witnessed 10x productivity differences under these definitions, too. My observation is that poor programmers get stymied by frameworks and environments they hardly grasp, and are either deathly afraid to touch anything or they try something and it breaks in horrendous unanticipated ways so they get paralyzed. A 10x programmer will not be paralyzed by fear but they will approach systematically. First you write unit tests for the existing code, so you understand the problem domain. Then you can start changing things and you'll know if you broke something because your unit tests will fail. Then you can start ripping out chunks of legacy code that is not actually needed anymore or was there to solve some hypothetical future problem that never materialized. To me the most important skill set in programming is time management and following a systematic approach to problems, as opposed to viewing programming as an art form and then feeling the oppressive weight of existing obstacles limiting your free spirit. The measure of good programming is not whether you solve that problem (that is a given) but by how much future headache your solution causes. Leave the world better than you found it.

chrisweekly 4y ago
>"To me the most important skill set in programming is time management and following a systematic approach to problems, as opposed to viewing programming as an art form and then feeling the oppressive weight of existing obstacles limiting your free spirit." THIS. Well said.
myownpetard 4y ago
I like your unit test example. I find that when approaching something new, like a codebase, API or framework, the most important thing to do after getting a cursory lay of the land, is establishing a tight feedback loop for determining if something is functioning/breaking/improving. In the case of refactoring, that's often adding test coverage as in your example. When experimenting with a new technology it's usually building a 'tracer bullet', the smallest e2e working piece of functionality to ensure that your mental model matches with the reality of how it actually works. The tools and processes of a technical org can have a big impact on how easy it is to take this approach. Enabling the engineers in your organization to create tight feedback loops and easily experiment is a huge boost to productivity. Test execution speed, ease of deploying dev instances of services or whole clusters of services, logs that are easy to access and query, distributed traces. At larger companies it can be a huge pain to simply spin up or get access to an instance of a service that you can poke, change, break and throwaway much less a cluster of interacting microservices.
deleted 4y ago
[deleted]
commandlinefan 4y ago
> The measure of good programming _ought to be, but isn't and never will be in the eyes of the people who are actually going to make it into a position of authority_ is not whether you solve that problem (that is a given) but by how much future headache your solution causes As Dilbert points out "our boss can't judge the quality of our work, but he knows when it's late". The only measure of good programming that will translate into actual tenure in an organization is: how fast did you get it done? It's been this way for 50 years. It won't end tomorrow just because you're right about the way things ought to be.
muskmusk 4y ago
What you are describing sounds like a good senior engineer. There can ofcourse be exceptions, especially if we talk about necessary complexity that has been turned into a swamp, but usually what you are describing is closer to x2 engineering. x10 is when you stop solving problems and make them vanish instead. An example: Business/product/whatever wants fuzzy search on a listing. x2 says "I know how to do that. We just use Debezium and kafka to get the data into Elastic Search and then query it from there". Business/product/whatever says "cool, code it up". The infrastructure is a little difficult, but two months later a well tested good solution is in production, everyone is happy. Good job? x10 says "how good does the fuzzy search need to be? Elastic Search is king, but Postgres can do it too". Business/product/whatever says "I don't know". x10 engineer codes a demo in 2 hours, shows it to business/product/whatever. Business/product/whatever says "that will do, lets ship it". The day after its shipped to production, noone ever talks about fuzzy search anymore. Noone is every consistently x2 or x10 or xWhatever. Sometimes x2 is the best you can do, but other times you can do much much better. The trick is usually to be on the lookout for it.
- ratww 4y ago
  I love this example as it hits close to home. I once, several years ago, worked on a team where nobody else knew there was full-text search inside Postgres. Took a few hours to convince, demonstrate and teach, but we got there. Took half that time to implement. Six months on, there were about 10 full-text queries per hour. Posgres is probably overkill for what we're doing, but since the data is there. Imagine if we had gone the ElasticSearch route. I still have fantasies of punching the guy who said "But if PostgreSQL has fulltext search, why would they had invented ElasticSearch"?
BeetleB 4y ago
> First you write unit tests for the existing code, so you understand the problem domain. Then you can start changing things and you'll know if you broke something because your unit tests will fail. In many projects this is a fantasy. I've yet to work on a C++ project where one could add (useful) unit tests to existing code without rearchitecting. If you don't design your code to use unit tests to begin with it won't be easy to add them later. Python, sure. C++: no way

by fefe23 4y ago

chrisweekly 4y ago

>"To me the most important skill set in programming is time management and following a systematic approach to problems, as opposed to viewing programming as an art form and then feeling the oppressive weight of existing obstacles limiting your free spirit." THIS. Well said.

myownpetard 4y ago

I like your unit test example. I find that when approaching something new, like a codebase, API or framework, the most important thing to do after getting a cursory lay of the land, is establishing a tight feedback loop for determining if something is functioning/breaking/improving. In the case of refactoring, that's often adding test coverage as in your example. When experimenting with a new technology it's usually building a 'tracer bullet', the smallest e2e working piece of functionality to ensure that your mental model matches with the reality of how it actually works. The tools and processes of a technical org can have a big impact on how easy it is to take this approach. Enabling the engineers in your organization to create tight feedback loops and easily experiment is a huge boost to productivity. Test execution speed, ease of deploying dev instances of services or whole clusters of services, logs that are easy to access and query, distributed traces. At larger companies it can be a huge pain to simply spin up or get access to an instance of a service that you can poke, change, break and throwaway much less a cluster of interacting microservices.

deleted 4y ago

[deleted]

commandlinefan 4y ago

> The measure of good programming _ought to be, but isn't and never will be in the eyes of the people who are actually going to make it into a position of authority_ is not whether you solve that problem (that is a given) but by how much future headache your solution causes As Dilbert points out "our boss can't judge the quality of our work, but he knows when it's late". The only measure of good programming that will translate into actual tenure in an organization is: how fast did you get it done? It's been this way for 50 years. It won't end tomorrow just because you're right about the way things ought to be.

muskmusk 4y ago

What you are describing sounds like a good senior engineer. There can ofcourse be exceptions, especially if we talk about necessary complexity that has been turned into a swamp, but usually what you are describing is closer to x2 engineering. x10 is when you stop solving problems and make them vanish instead. An example: Business/product/whatever wants fuzzy search on a listing. x2 says "I know how to do that. We just use Debezium and kafka to get the data into Elastic Search and then query it from there". Business/product/whatever says "cool, code it up". The infrastructure is a little difficult, but two months later a well tested good solution is in production, everyone is happy. Good job? x10 says "how good does the fuzzy search need to be? Elastic Search is king, but Postgres can do it too". Business/product/whatever says "I don't know". x10 engineer codes a demo in 2 hours, shows it to business/product/whatever. Business/product/whatever says "that will do, lets ship it". The day after its shipped to production, noone ever talks about fuzzy search anymore. Noone is every consistently x2 or x10 or xWhatever. Sometimes x2 is the best you can do, but other times you can do much much better. The trick is usually to be on the lookout for it.

ratww 4y ago
I love this example as it hits close to home. I once, several years ago, worked on a team where nobody else knew there was full-text search inside Postgres. Took a few hours to convince, demonstrate and teach, but we got there. Took half that time to implement. Six months on, there were about 10 full-text queries per hour. Posgres is probably overkill for what we're doing, but since the data is there. Imagine if we had gone the ElasticSearch route. I still have fantasies of punching the guy who said "But if PostgreSQL has fulltext search, why would they had invented ElasticSearch"?

BeetleB 4y ago

> First you write unit tests for the existing code, so you understand the problem domain. Then you can start changing things and you'll know if you broke something because your unit tests will fail. In many projects this is a fantasy. I've yet to work on a C++ project where one could add (useful) unit tests to existing code without rearchitecting. If you don't design your code to use unit tests to begin with it won't be easy to add them later. Python, sure. C++: no way