6 ms·

There is art to it. I wonder if it can be taught.

niho 6y ago
Art schools that teach you visual art and craft is a thing. So I don’t see why it would be impossible to teach the art of building software. We just need to change our methods.
waheoo 6y ago
Pragmatic programmer does a decent job of it. Not perfect, but decent enough. I'm of the school that thinks it's something you need to practice. Many software positions especially in large companies are very limited in scope, you basically just maintain and patch existing systems, rarely having to build systems from scratch. Building these systems from the ground up is what is hard but you learn what works and what doesn't the more you do it. If you want to learn how to build software, join a start up or small company that has a healthy appreciation for what software rewrites can provide. Run away from companies that follow the never rewrite mantra. Usually saying something like you'll just repeat mistakes, its like well no shit this thing was built before I was born, if you rebuilt it with me here I could avoid those mistakes. I'm not saying you should always rewrite, its usually better to refactor, but some design failures are hard to refactor out, have double binds or are too critical for stability woes. But systems that live forever should have unlimited quality assurance budgets for refactor and repair, very few do in this industry. Managers seem to expect systems to live forever all while constantly patching with very small refactoring budgets. It's completely insane. Like running a machine in a factory 24/7 and never doing maintenance but expecting it to work perfectly like new forever with no future cost incurred as eventual debt.
- Twisol 6y ago
  > Managers seem to expect systems to live forever all while constantly patching with very small refactoring budgets. It's completely insane. Preach it! I don't know where this mentality comes from, but it seems to treat software as something that just magically solves problems and only needs a little upkeep to chug along. The problem is that problems change, and a different problem is no longer necessarily a solved problem. It takes a lot of design effort to make something that can easily be adapted to changes in the problem space, and it still requires effort to make sure the software doesn't specialize itself over time into a corner.
  - waheoo 6y ago
    Yup! And then sometimes it's actually advantageous to specialise systems into a corner, it has benefits, but these decisions need to be considered and made with care, and then it needs to be an understood limitation going forward that it can't be rolled back at a later time without a high cost. Thinking about the above further I notice the things I've learned over the years also require the ability to link problem to cause, or in my case it came in reverse, cause linked to problem. I ran into problems for years, learned how to fix them, and then during code reviews (even in self review), discovered the cause behind these problems. Sometimes these were causes that would only become problems at a later date because of knock on effects. I don't know how you teach that. Possibly antipatterns / code smells which usually hint at underlying problems that may be elsewhere / at a different level. Refactoring by Fowler and TDD by Beck cover a lot of these in good detail.
    - disgruntledphd2 6y ago
      Refactoring is an amazing book, but I think most people would be better served by starting with working effectively with legacy code, as it shows you how to get to a place where you can refactor confidently. The examples are kinda dated but the approach is pretty timeless.
      - chrisweekly 6y ago
        That'd be "Working Effectively with Legacy Code" by Feathers -- which I now look fwd to reading; thanks for the rec!
      - waheoo 6y ago
        I tend to disagree but this might be my biases at play. Refactoring starts from first principles, almost all examples include the reverse refactoring as often you need to undo optimisations a few steps before you can move forward in a different direction. I was recommended working effectively with legacy code by the same types of managers that expect forever returns off the same code. They like to point out how that book encourages small patching without refactoring as refactoring is often fruitless in short term money terms, whereas Fowler tends to advocate refactoring as a healthy and necessery part of software development. I can't say I hated working effectively. I found TDD by Beck more useful, and working effectively with unit tests to also be worthwhile. All of these books cover a lot of similar ground. If you're going to read only one or two I suggest TDD > refactoring and avoiding the others. (Just my opinion based on what I got out of them reading after 10 years on the job, I suspect juniors might have a different take)
marketingPro 6y ago
I would feel significantly more comfortable calling programming an art rather than science or Engineering. I was an engineer before switching to programming and despite throwing the word Software Engineer in my title, there is no Engineering. There is developing only. 'best practices' come from Authority, not science(note at bottom). This is a stark contrast to Engineering where everything is proven with math. (Note)We don't write in logic gates anymore, efficiency is obscure at modern coding levels.
- MaxBarraclough 6y ago
  > This is a stark contrast to Engineering where everything is proven with math. You've just described the field of formal methods. For software with strict requirements of correctness, correctness is sometimes proven mathematically. It's not that a rigorous approach to software development is impossible, it's more a question of when it's really worth doing. At present, formal methods are very costly to use. I don't think it's always necessary to go all the way to full formal verification for software development to count as rigorous, though. Related reading: They Write the Right Stuff, from 1996. [0] > efficiency is obscure at modern coding levels Depends on the domain. There are plenty of domains where efficiency doesn't much matter, on modern hardware. Game engines are still tuned for efficiency, and will continue to be. [0] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
  - marketingPro 6y ago
    To clarify, you cant know what is the most efficient path in Programming. You can modify and time, but you can't know ahead of time.
    - MaxBarraclough 6y ago
      I don't see the point here. It's quite possible to assess the performance of a game-engine.
      - 6y ago
deleted 6y ago
[deleted]
franzwong 6y ago
After writing code for 20 years, I found out there are different interpretations of "simplicity", just like an art.
crispyambulance 6y ago
> I wonder if it can be taught. Of course it can be taught, it has to. The current model of expecting people to just pick it up on their own by going to school or a bootcamp isn't working. I think a large part of the problem is that in contemporary workplaces it's becoming rare for senior talent to spend serious time developing juniors and doing so as an integral part of their job rather than merely within the scope of some mandated "knowledge transfer" phase. To many places are beset with pushy "deliverables" treadmills and suffocating project management. It's hard, especially in large organizations, to just "think" and be creative. Juniors need to see that, emulate it, and get meaningful feedback beyond a dumb burn-down chart.
BurningFrog 6y ago
I learned most of it through pair programming. You teach each other. With solo programming, everyone has to figure everything by themselves. A deeply inefficient system.
elevenoh 6y ago
Any thought pattern can be compressed, transferred & applied I'd say.

niho 6y ago

Art schools that teach you visual art and craft is a thing. So I don’t see why it would be impossible to teach the art of building software. We just need to change our methods.

waheoo 6y ago

Pragmatic programmer does a decent job of it. Not perfect, but decent enough. I'm of the school that thinks it's something you need to practice. Many software positions especially in large companies are very limited in scope, you basically just maintain and patch existing systems, rarely having to build systems from scratch. Building these systems from the ground up is what is hard but you learn what works and what doesn't the more you do it. If you want to learn how to build software, join a start up or small company that has a healthy appreciation for what software rewrites can provide. Run away from companies that follow the never rewrite mantra. Usually saying something like you'll just repeat mistakes, its like well no shit this thing was built before I was born, if you rebuilt it with me here I could avoid those mistakes. I'm not saying you should always rewrite, its usually better to refactor, but some design failures are hard to refactor out, have double binds or are too critical for stability woes. But systems that live forever should have unlimited quality assurance budgets for refactor and repair, very few do in this industry. Managers seem to expect systems to live forever all while constantly patching with very small refactoring budgets. It's completely insane. Like running a machine in a factory 24/7 and never doing maintenance but expecting it to work perfectly like new forever with no future cost incurred as eventual debt.

Twisol 6y ago
> Managers seem to expect systems to live forever all while constantly patching with very small refactoring budgets. It's completely insane. Preach it! I don't know where this mentality comes from, but it seems to treat software as something that just magically solves problems and only needs a little upkeep to chug along. The problem is that problems change, and a different problem is no longer necessarily a solved problem. It takes a lot of design effort to make something that can easily be adapted to changes in the problem space, and it still requires effort to make sure the software doesn't specialize itself over time into a corner.
- waheoo 6y ago
  Yup! And then sometimes it's actually advantageous to specialise systems into a corner, it has benefits, but these decisions need to be considered and made with care, and then it needs to be an understood limitation going forward that it can't be rolled back at a later time without a high cost. Thinking about the above further I notice the things I've learned over the years also require the ability to link problem to cause, or in my case it came in reverse, cause linked to problem. I ran into problems for years, learned how to fix them, and then during code reviews (even in self review), discovered the cause behind these problems. Sometimes these were causes that would only become problems at a later date because of knock on effects. I don't know how you teach that. Possibly antipatterns / code smells which usually hint at underlying problems that may be elsewhere / at a different level. Refactoring by Fowler and TDD by Beck cover a lot of these in good detail.
  - disgruntledphd2 6y ago
    Refactoring is an amazing book, but I think most people would be better served by starting with working effectively with legacy code, as it shows you how to get to a place where you can refactor confidently. The examples are kinda dated but the approach is pretty timeless.
    - chrisweekly 6y ago
      That'd be "Working Effectively with Legacy Code" by Feathers -- which I now look fwd to reading; thanks for the rec!
    - waheoo 6y ago
      I tend to disagree but this might be my biases at play. Refactoring starts from first principles, almost all examples include the reverse refactoring as often you need to undo optimisations a few steps before you can move forward in a different direction. I was recommended working effectively with legacy code by the same types of managers that expect forever returns off the same code. They like to point out how that book encourages small patching without refactoring as refactoring is often fruitless in short term money terms, whereas Fowler tends to advocate refactoring as a healthy and necessery part of software development. I can't say I hated working effectively. I found TDD by Beck more useful, and working effectively with unit tests to also be worthwhile. All of these books cover a lot of similar ground. If you're going to read only one or two I suggest TDD > refactoring and avoiding the others. (Just my opinion based on what I got out of them reading after 10 years on the job, I suspect juniors might have a different take)

marketingPro 6y ago

I would feel significantly more comfortable calling programming an art rather than science or Engineering. I was an engineer before switching to programming and despite throwing the word Software Engineer in my title, there is no Engineering. There is developing only. 'best practices' come from Authority, not science(note at bottom). This is a stark contrast to Engineering where everything is proven with math. (Note)We don't write in logic gates anymore, efficiency is obscure at modern coding levels.

MaxBarraclough 6y ago
> This is a stark contrast to Engineering where everything is proven with math. You've just described the field of formal methods. For software with strict requirements of correctness, correctness is sometimes proven mathematically. It's not that a rigorous approach to software development is impossible, it's more a question of when it's really worth doing. At present, formal methods are very costly to use. I don't think it's always necessary to go all the way to full formal verification for software development to count as rigorous, though. Related reading: They Write the Right Stuff, from 1996. [0] > efficiency is obscure at modern coding levels Depends on the domain. There are plenty of domains where efficiency doesn't much matter, on modern hardware. Game engines are still tuned for efficiency, and will continue to be. [0] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
- marketingPro 6y ago
  To clarify, you cant know what is the most efficient path in Programming. You can modify and time, but you can't know ahead of time.
  - MaxBarraclough 6y ago
    I don't see the point here. It's quite possible to assess the performance of a game-engine.
    - 6y ago

deleted 6y ago

[deleted]

franzwong 6y ago

After writing code for 20 years, I found out there are different interpretations of "simplicity", just like an art.

crispyambulance 6y ago

> I wonder if it can be taught. Of course it can be taught, it has to. The current model of expecting people to just pick it up on their own by going to school or a bootcamp isn't working. I think a large part of the problem is that in contemporary workplaces it's becoming rare for senior talent to spend serious time developing juniors and doing so as an integral part of their job rather than merely within the scope of some mandated "knowledge transfer" phase. To many places are beset with pushy "deliverables" treadmills and suffocating project management. It's hard, especially in large organizations, to just "think" and be creative. Juniors need to see that, emulate it, and get meaningful feedback beyond a dumb burn-down chart.

BurningFrog 6y ago

I learned most of it through pair programming. You teach each other. With solo programming, everyone has to figure everything by themselves. A deeply inefficient system.

elevenoh 6y ago

Any thought pattern can be compressed, transferred & applied I'd say.