51–60 of 74 posts
Initial implementation speed is one of the least important parameters in software engineering. Senior engineers are generally a bit slower but produce higher quality code. It's MUCH better to have an engineer which takes 3 days to implement a feature in such a way that it doesn't need to be revised/fixed again for at least 1 year than to have an engineer which takes 4 hours to build that same feature but in such a wa…
Earlier quoted context omitted.
Tutorials don't cover things like corner cases, and they neglect nearly every aspect of designing and integrating a large system, particularly scaling it. Some of the worst code I've ever seen was "tutorial code." I've encountered concurrency challenges in my day-to-day work that have no cookie cutter solutions, are specific to my application (particularly in constraints and requirements), and I haven't even been abl…
I might add that the difference between a hacked together kernel and the Linux kernel is HUGE. "Hacked together" projects are full of weird bugs, incorrect concurrent code that still works 99+% of the time but then rarely crashes and burns when that ill-anticipated failure case execution interleaving randomly strikes -- to say nothing of problematic and unrefined UX. Well-designed projects are a work of beauty.
That sounds like an accurate description of 95% of existent software in the world.
I would think the speed ratio between the best and worst programmers has to be infinite. Some programmers simply cannot accomplish a task. Once they die you may as well divide by infinity. For every task you need some minimal iq. Some tasks need higher iq than others. A programmer is someone who can at least do the least iq requiring task. He will fail on some more difficult tasks. Iq just a standin for mental comput…
Initial implementation speed is one of the least important parameters in software engineering. Senior engineers are generally a bit slower but produce higher quality code. It's MUCH better to have an engineer which takes 3 days to implement a feature in such a way that it doesn't need to be revised/fixed again for at least 1 year than to have an engineer which takes 4 hours to build that same feature but in such a wa…
How do you explain that to companies that follow the Google interviewing model?
I'm pretty sure that I'm a "slow" developer. Not in terms of actually coming up with the core fix to a problem that I'm working on (that's actually the most straightforward part of any project) but everything else that follows. That is to say writing clean, well-tested, documented and maintainable code. Is this something to be concerned about long-term or should I just accept that my work will always take a little lo…
Find fast people to pair program with. You'll learn some good speedup techniques.
Initial implementation speed is one of the least important parameters in software engineering. Senior engineers are generally a bit slower but produce higher quality code. It's MUCH better to have an engineer which takes 3 days to implement a feature in such a way that it doesn't need to be revised/fixed again for at least 1 year than to have an engineer which takes 4 hours to build that same feature but in such a wa…
The only problem with this (correct) approach is that somebody has to be able to foresee what happens in 1 year. Since it is a relatively rare skill, many decision makers choose quick and dirty solution.
Finding metrics which work well even when people try to game them is incredibly difficult (if not impossible).
I would think the speed ratio between the best and worst programmers has to be infinite. Some programmers simply cannot accomplish a task. Once they die you may as well divide by infinity. For every task you need some minimal iq. Some tasks need higher iq than others. A programmer is someone who can at least do the least iq requiring task. He will fail on some more difficult tasks. Iq just a standin for mental comput…
Can you give an example of an "IQ requiring task"? I'd buy that there are programs you can't write without the proper background knowledge, but I don't understand what IQ has to do with any of this.
Apply the Intermediate Value Theorem to this example, as needed.
> [] Three of the twelve subjects did not use the recommended high-level language JTS for solving the task, but rather programmed in assembly language instead. Two of these three in fact required the longest working times of all subjects. One might argue that the decision for using assembly is part of the individual differences, but presumably most programmers would not agree that doing the program in assembly is the same task as doing it in a high-level language.
In my experience, making the right decisions like that is the real difference between good and not so good programmers. Good programmers do on average better choices that results in less code, code that is easier to maintain and reason about, and choosing language and architecture that fit the problem at hand. It is not that good programmers develop so much faster usually.
I would think the speed ratio between the best and worst programmers has to be infinite. Some programmers simply cannot accomplish a task. Once they die you may as well divide by infinity. For every task you need some minimal iq. Some tasks need higher iq than others. A programmer is someone who can at least do the least iq requiring task. He will fail on some more difficult tasks. Iq just a standin for mental comput…
I think what you call it is more complex. As I can see there are three important capacitities: attention to details, working memory and iq (capacity to see patterns, what is tested in iq tests). In my experience they are all important, I'm pretty bad at the first two, and this makes me miserable in my job.
Working memory: Memorize things that surprise you. Then Try to understand why you were surprised. You don't have to memorize things you understand.