91–100 of 223 posts
The master potter does not churn out pots that need to be fixed. He focuses on quantity to get to quality faster, that is the whole point of that story in my opinion.
Also, "refactoring code" should not be seen as such a separate activity that it can (or should) be done by other people.
Earlier quoted context omitted.
Nah. He just got distracted by the trappings of being famous.
No, he had written himself into a corner at the end of the "Dance of Dragons", and then waited for the tv show screenwriters to help him figure out how to proceed from there - that's the most probable explanation I can come up with (hinted by some statements from his interviews).
I'm definitely a little bitter about it, but I've accepted it. Parris needs the royalties.
/salt: Somehow, within that time, Robin Hobb managed to spit out a trilogy seemingly once a quarter. Thankfully, Steven Erikson came along and wrote The Malazan Book of the Fallen, which, if you like books, honestly puts ASoIaF to shame on numerous levels (and has the benefit of being done).
Someone 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…
For me, part of being "expert" is having broad experience, and that takes time. I think I would have used "expert" to describe my abilities after somewhere between 5 and 10 years.
People 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 think it’s a balance. At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code.
Earlier 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?
The only thing I know is I worked on many projects at many companies for the last 15 years. This gives some confidence :)
Please stop thinking there are 10x programmers - or perhaps stop thinking it means 10x better . It is simply 10x more valuable . And that depends on the organisation you work for, the state of the code base and so on. Look at it this way - sports stars are regularly 10x, 100x more valuable to their team management than A.N.Other professional player. Take football (soccer) - Ronaldo is a waaaay better player than I am…
Take, for example, the median level 1x programmer. Perhaps a Java programmer working at a large tech corporation on a team of 1000+ in Indonesia or Brazil.
That guy isn't visiting HN. That guy doesn't read tech articles at home. He may join a few programmer groups on Reddit or Facebook. But his main concern is that he gets paid and feeds his family. He doesn't care so much about doing his work well, but he cares that he does it well enough to make a 10% salary raise each year.
He can probably reverse a linked list. But his searches are all O(n^2), and he can't do any less. The company that hires him doesn't really care - they're unfamiliar that things can be better, and as far as they know, they'd rather get hire ten $15k guys than a single $150k star programmer.
Is it possible to code 3x faster than that guy? Certainly. Especially when it comes to harder parts of the work.
Is it possible to code 3x better? As in code that's more efficient and doesn't crash as much? Also very likely.
And someone who codes 3x faster also reduces the cost of the project drastically - you can pay a team one month wages instead of three.
Now you put these multipliers together, you get easily more than 10x, quantifiably.
Sports players may try to run 100m a second faster, but star programmers can easily build a project faster and cheaper.
Earlier quoted context omitted.
I think it depends on how much time they spend programming and what they program. 1. There's a difference between 3 years of experience 4 hours a day 5 days a week and 9 hours a day 7 days a week. That's 20 hours vs 63 hours per week. Furthermore, the 63-hours-per-week person has all of that experience in the last 3 year context. A 20 hours-per-week person would take 9 years to get the same amount of experience in te…
This is about swimmers: https://fermatslibrary.com/s/the-mundanity-of-excellence-an-... but it's a counter to the popular idea that "more work" is what it takes to become better at something. Two people in the same group will find that the one who tries more will get better results, but training for more time won't get them to a better group. Instead, qualitative changes are needed - probably many of them - people to…
People 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 think it’s a balance. At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code.
If I have to pick, I’d err on the side of doing more than trying to slow down and write perfect code. When you’re junior, your definition of “perfect” code might be very different from others’. You might be reinforcing bad habits rather than learning. I’ve seen junior SWEs insist on spending hours eliminating a couple lines of duplicated code by pulling them out into functions to achieve their perfect code. At the same time, they neglect basic coding hygiene, put defensive nullptr checks everywhere, and not design for readability and testing.
People 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 think it’s a balance. At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code.
In the end, all code is debt. The only thing is whether you earned anything from the debt. If you never earn anything it doesn't matter that you didn't take on that much debt.