FYI the ceramics story comes from a book called "Art and Fear" which I highly recommend to any creative individual.
Programming: Doing it more vs. doing it better
181–190 of 223 posts
Re: Programming: Doing it more vs. doing it better
#182People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. How to recognise the former group: they obsess about coding and other standards and processes, plan and discuss too long how to implement something (plan what to implement, do it, then improve it…
The issue here isn't beautiful code vs quick code.
I think it's between spending some time and thinking about the problem you are trying to solve vs brute forcing a quick prototype to get it done.
I think your code will look beautiful by itself if the engineer fully understands the problem at hand.
This process takes time and practice. I personally throw away my quick first solution and let the fog clear first.
Somethings that have generally given me good results: drawing stuff, taking small breaks, listening to my tests (if my tests hurt, it means my design is bad)
Would love to hear other thoughts on this !
Re: Programming: Doing it more vs. doing it better
#183People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. How to recognise the former group: they obsess about coding and other standards and processes, plan and discuss too long how to implement something (plan what to implement, do it, then improve it…
I've "finish[ed] more correct programs on time" by planning all of the details in a Design Document before writing a line of code, than I ever have by planning at a high level only before implementing, but that's just my personal anecdote. Although, I do take the MVP-then-iterate approach if I don't have a tight deadline, because the early feedback loop can be invaluable in that type of development process.
Re: Programming: Doing it more vs. doing it better
#184Earlier quoted context omitted.
While 3 years isn't much from a whole career perspective, I do believe those may be the three most important years, where you learn the most etc; I'm at about 10 years now, and don't feel like my level has significantly improved since then. I mean sure, I'm more experienced now and know more languages etc etc, but it's not like I'm 10x more productive or smart or better than I was 10 years ago.
Is "10x more productive" even the right way to assess ourselves? I may be writing 1.5 times as much code as I was 2 years ago, but that code per line is much more sophisticated and gets a lot more work done, as I've learned more and more libraries and learned more tips/tricks/shortcuts.
I would say that your description is indeed of someone who's "more productive"
> code [...] is much more sophisticated and gets a lot more work done > [familiar with] more and more libraries > I've [...] learned more tips/tricks/shortcuts
I'd even throw something like "code is closer to correct on the first revision" into the productivity column.
Re: Programming: Doing it more vs. doing it better
#185Someone who's been programming for three years is still a beginner, even though based on what he wrote here, Kevin is almost certainly a lot better than I was when I'd been programming for only three years. I do find that a lot of programming stuff that used to be hard is easier for me now that I've been progrmaming for 38 years. But that doesn't mean I spend all my time doing things I can do without thinking, and it…
While 3 years isn't much from a whole career perspective, I do believe those may be the three most important years, where you learn the most etc; I'm at about 10 years now, and don't feel like my level has significantly improved since then. I mean sure, I'm more experienced now and know more languages etc etc, but it's not like I'm 10x more productive or smart or better than I was 10 years ago.
Weird, I feel I'm still improving a lot after 15 years but perhaps doing new stuff just keeps challenging what you know.
Re: Programming: Doing it more vs. doing it better
#186Someone who's been programming for three years is still a beginner, even though based on what he wrote here, Kevin is almost certainly a lot better than I was when I'd been programming for only three years. I do find that a lot of programming stuff that used to be hard is easier for me now that I've been progrmaming for 38 years. But that doesn't mean I spend all my time doing things I can do without thinking, and it…
Someone programming for 3 yrs is not a beginner, There are people programming at 3 yrs that are experts and will run circles around you and your 38 years. Some people really have the talent and put in the work to get good. In 2019, the mentorship is available via means of books, blogs, MOOC, youtube videos, conferences. What some folks can achieve in 3 yrs these days is really unbelievable. P/S, I have been hacking a…
3 years of professional experience (and working on mobile applications as side gigs since 12 after their dad teached them how to do simple scripts with PHP at 8)
I can believe that.
Re: Programming: Doing it more vs. doing it better
#187People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. How to recognise the former group: they obsess about coding and other standards and processes, plan and discuss too long how to implement something (plan what to implement, do it, then improve it…
I despise this kind of mentality which tries to demonize someone's passion to actually write a beautiful code. This kind of mentality takes away "the human factor" from the working environments turning IT jobs into delivery driven factories. I for one need to enjoy my work to actually be productive. And don't get me wrong - I understand that product people need to deliver products and they enjoy doing their diagrams…
> meaning - correct, performant, maintainable, understandable, clever and so on
My favourite part of this is how often these criteria are essentially at odds.
- Understandable *and* performant?
- Clever *and* maintainable?
Re: Programming: Doing it more vs. doing it better
#188Earlier quoted context omitted.
I despise this kind of mentality which tries to demonize someone's passion to actually write a beautiful code. This kind of mentality takes away "the human factor" from the working environments turning IT jobs into delivery driven factories. I for one need to enjoy my work to actually be productive. And don't get me wrong - I understand that product people need to deliver products and they enjoy doing their diagrams…
> meaning - correct, performant, maintainable, understandable, clever and so on My favourite part of this is how often these criteria are essentially at odds. - Understandable *and* performant? - Clever *and* maintainable? But, you know, I'm also bad at all this so maybe it's just me :p
Yeah, I didn't really mean everything at once, I just wanted to make clear that "the beautiful" can be disaggregated into some engineering qualities.
Re: Programming: Doing it more vs. doing it better
#189People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. How to recognise the former group: they obsess about coding and other standards and processes, plan and discuss too long how to implement something (plan what to implement, do it, then improve it…
Like everything, it depends.
I think you're right for some classes of problems.
For others, going slow and painstakingly seeking to simplify is the only way. Otherwise the complexity will eat you alive and the whole edifice will collapse on itself.
Re: Programming: Doing it more vs. doing it better
#190People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. How to recognise the former group: they obsess about coding and other standards and processes, plan and discuss too long how to implement something (plan what to implement, do it, then improve it…
> Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. Generally done by people who don't think through the requirements or know why they're doing what they're doing. "I just copied pasted the example and hacked it until it did what i wanted. I'm still not sure why it works lol" Completely fucking over the next person who has to work that code.
It would be much easier if the next person were the creator of the code, but instead we have this machine cog mindset of "we can just throw any of our developers at any given problem whenever".