I've had this conversation a million times. I think when you're learning and working on your own to build a skill, do it fast and do it over and over. When you're working on a shared code base, you need to be more cognizant of your actions, of maintaining the established styles and conventions. I've know very few 10x or 100x programmers, and am not one myself. But I have had to deal with people who sacrificed quality for speed and every time a code review for those kind of people comes my way, I know I'm in for a ride that will take me away from the work I need to be doing.
Programming: Doing it more vs. doing it better
161–170 of 223 posts
Re: Programming: Doing it more vs. doing it better
#162This article is good, but these conversations here on HN always bug me.
Yes—write a ton of code.[0] Just do it. Make your favourite couple languages extensions of yourself.
Yes—think through your code really clearly. Spend a day on your migration or other data-structure altering changes. They're going to echo throughout your whole application and, ultimately, organization.
[0] The closer you get to the API, the faster you should code. Not the interface definition itself, that should be thought through, but the code that responds to a call to the interface. The serializer, the part of the controller that calls the render, these parts are easy. Just roll them out. The models and migrations are much more important. Spend time there. It's not an all or nothing thing.
Re: Programming: Doing it more vs. doing it better
#163People 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.
Re: Programming: Doing it more vs. doing it better
#164Someone 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.
I suspect it depends on what you're building. Some problems in computing are drastically harder than others. Crud-like web applications, for example, are a well-trodden path now, but there are many applications of software that are not as straight forward.
Re: Programming: Doing it more vs. doing it better
#165Earlier quoted context omitted.
I have seen way more damage done by the people "mostly working prototypes in hours or days" than people who want to write beautiful code. I understand that fixation to produce something beautiful can lead to paralysis but this is rarely the case. In most cases the prototype grows cancerously and it becomes impossible to fix in quite short time, my advice, listen to the experienced programmers who screwed up more time…
Most of the damage I've seen was from people who think they can write beautiful code, but instead write a slow overengineered framework and use clout to force everyone else's code into that framework. Sadly, these people are often smart and experienced. It's more of an attitude problem: they are not content with making a library that will sit at the bottom of the call stack, when they could instead make a framework t…
I've worked at a couple companies now that have this problem. I know that one is now on their third try at a second gen rewrite of their aging core product. They can't ship it because they haven't found that magic formula to make it the most perfect program ever[0]. Sadly, this has been with multiple teams trying.
[0] I call this the Neo Architecture. They're looking for "the one". The architecture that will allow for any CR to be handled elegantly and beautifully, where all concerns are completely separated, where all data is perfectly abstracted. There's no such thing. It doesn't exist. Just ship already!
Re: Programming: Doing it more vs. doing it better
#166Earlier quoted context omitted.
"Please stop thinking there are 10x programmers" I don't really agree, since I consider myself a 10x engineer. I have countless of examples of guys struggling for 2 months on some project. They get stuck, ask for help and I look at it and build it from scratch in a week. It's not I'm typing faster, it's more about choosing the right architecture and libraries. You can save insane amounts of time by making the right d…
> I have countless of examples of guys struggling for 2 months on some project. They get stuck, ask for help and I look at it and build it from scratch in a week. Are you a 10x engineer or are they 0.1x engineers and how do you differentiate the two?
[deleted]
Re: Programming: Doing it more vs. doing it better
#167Earlier quoted context omitted.
Interesting view. I'm learning, with about 8 months worth of knowledge and experience, and this is useful. Did you notice any skills/traits in those people who were "unbelievable" in those 3 years? For instance, did they do "test driven development"? Also, did they keep good log habits?
I think OP has provided good context. But I will try to answer the question you _really_ seem to be asking: unfortunately there is no shortcut. There are things you can do that will, like the author said, give you faster feedback and thus let you get better _if_ you use that feedback. You might write a lot of code and read a lot of code and internalize good patterns. Eventually you will have enough experience and the…
For me the biggest learning experience was building a system for a company, (a moderately complex CRUD app at the end of the day) and maintaining it for 4+ years.
If I had to go back and modify the code, if I didn't understand it straight away then it was usually worth refactoring. It was my own code so I had no one else to blame if it was crap.
That probably has expanded into reading others code and seeing better ways of doing things like you say.
Re: Programming: Doing it more vs. doing it better
#168People 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…
Also known as the difference between doing things right (beautiful code) vs doing the right thing (working software).
I like ideas from the systems thinkers like Russell Ackoff about this.
> Ackoff expands by suggesting that doing things right is about efficiency but doing the right thing is about effectiveness. He makes a strong case for the connection between wisdom and doing/identifying the right things. He notes further that when we try to do things right about the wrong thing, we actually make things worse. Such attempts at improvement actually take us further from both the recognition and accomplishment of the “right thing”.
https://ackoffcenter.blogs.com/ackoff_center_weblog/2018/04/...
Re: Programming: Doing it more vs. doing it better
#169People used to heavily criticise Minecraft from a technical point of view. Their criticisms were often entirely reasonable - it was at one point a very inefficient and unstable piece of software. However, it's now the second best-selling game of all time. Sometimes it's better to churn out a release and fix the problems later than let quality worries block you from achieving anything.
Re: Programming: Doing it more vs. doing it better
#170Earlier quoted context omitted.
Indeed. I love it when the amount of money I make is tied to the quality of my code somehow. Easy to modify, easy to repurpose, easy to replace. These often make it possible to serve customers better -> more $$$ It's why I can't really take a regular job. There is no relationship between the quality of my work and what I get paid.
In my experience, even programmers are poor judges of good quality of code. Usually the criteria they are using to evaluate quality is: "Can I do what I want to do quickly?" This tends to boil down pretty quickly to "Is the code similar to code I've worked on recently?" Understanding the long term consequences of your actions is pretty tough and the ground keeps shifting under your feet. In that environment, having s…
> I believe that if you are able to consistently achieve a result of "projects with this person tend to have fewer problems than projects without this person", it will translate into more $$$.
Bingo.