21–30 of 225 posts
- Competition/Compensation for experienced coders has risen sharply
- There are many more inexperienced SDE's coming from colleges/bootcamps/etc
- Senior titles are often given to individuals who are still very early in their careers
Now, these factors might be necessary/good in the short term as software continues to eat the world.
But, let's not pretend that the talent shortage isn't a problem.
TL;DR: "[Coding perfectly and anticipating any possible change to how the tools work] are not reasonable expectations of a human being. We need languages with guard rails to protect against these kinds of errors." I definitely agree with this. And it also applies to a lot more than what the article is focused on (low-level security). It seems that right now the entire programming ecosystem seems to jump to "you just…
I'm torn on this, because while we can always do better, sometimes there's things you just gotta know; this is the best we can do, so far. There's also lots of lazy programmers, that think everything should be easy and intuitive, when in reality they need to do more to understand the tools they have and hone their craft. I refuse to call them bad, because I think most people can reach expert level. Maybe not master o…
Even with the tools there are plenty of bugs/challenging problems in just understanding and correctly expressing the problem domain in those safe and intuitive tools.
The two positions are not incompatible.
No need to say 'bad', but there is definitely a shortage of experienced coders. - Competition/Compensation for experienced coders has risen sharply - There are many more inexperienced SDE's coming from colleges/bootcamps/etc - Senior titles are often given to individuals who are still very early in their careers Now, these factors might be necessary/good in the short term as software continues to eat the world. But,…
Your issues in recruiting interviewing and oboarding are not the fault of tech workers.
>> The problem is that the database connection would sometimes use a re-entrant mutex when it was acquired from the pool...
>> with a normal mutex we would be fine, since you only one lock can exist and it doesn’t matter if we unlock it on a thread other than the one we locked it from...
>> Fundamentally, we just can’t have a re-entrant mutex be involved and also be able to pull the connection from the pool on a different thread than it is being used...
Truly good coders are very rare because it's not just about mastering all the available tools and abstractions, it's also about the ability to come up with abstractions that make it simple for anyone looking at the code to understand what is happening.
Good coders can write simple code to do complex things.
I can see how this article might be comforting for some, but "bad coders" is still a problem. There are a lot of amateurs in this industry (even ones with years of "experience"). You can create an extremely opinionated language which doesn't give any freedom for creativity, solutions and expression, and devs will still find a way to duck everything up. IMHO, OP saw a problem but didn't arrive to the right solution.
It's good to have bad coders. Not everybody can have an exceptional IQ. Not everybody can be good, but everybody deserves a chance to be a coder. There are real problems that can be solved by a bad coder as well, that may help your life some day. Great coders are needed for large, scalable, hard problems, but there are little things they don't have time to work on.
Also when can we finally drop this IQ thing? Your IQ does not guarantee you anything. Attention to details, perseverance, curiosity are the great promising qualities, not your IQ.
No need to say 'bad', but there is definitely a shortage of experienced coders. - Competition/Compensation for experienced coders has risen sharply - There are many more inexperienced SDE's coming from colleges/bootcamps/etc - Senior titles are often given to individuals who are still very early in their careers Now, these factors might be necessary/good in the short term as software continues to eat the world. But,…
Experienced programmers know they don't have to settle for less.
In general, in favor of as many correctness and other checks at compile time as possible. Make tools as powerful as possible. I really liked this tweet: "What if... - your programming language required you to write useful docs, - using those docs, it checked your program for mistakes, - it even used the docs to speed up your program, - this feature already exists! And what if it was called static typing." - https://t…
I do part time work as an external examiner, sometimes for first year CS students, so I get to see a lot of silly code. Like the result of having been tasked with doing Fibonacci recursively. Which, as most of you no doubt are aware, can be done correctly in several different ways. The most basic is to simply implement it with its two base cases and run it until you meet them for every sequence. A more efficient way is to implement it with a way of keeping track of Fibonacci sequences that you have already computed, as to not do them more than once.
Both these ways work perfectly fine within the toolset, one just does it a lot better.
I remember when I first added ESLint to our large JavaScript codebase, and then again when I added Flow. I'm a perfectionist when I code, but it was shocking to see some of the things I'd written. Mistakes that I thought were so unlike me, but had been sitting there for months anyway, waiting to blow up. The human brain wasn't designed to handle the complexity of large codebases. There are just too many compounding i…
The first time I ran a static analyser over an old codebase of mine it was deeply humbling.
I'm a competent programmer who works deliberately and carefully and the tool still went "did you really mean to do this stupid thing?".
Of course sometimes you do mean to do stupid thing because there is a good reason for it and as long as the tool gives you the ability to say // @allow-stupid-thing: punch-myself-in-face it's all good.
Since then I throw as many linters, formatters and static analyses tools as I can reasonably get my hands on at every codebase.
In general, in favor of as many correctness and other checks at compile time as possible. Make tools as powerful as possible. I really liked this tweet: "What if... - your programming language required you to write useful docs, - using those docs, it checked your program for mistakes, - it even used the docs to speed up your program, - this feature already exists! And what if it was called static typing." - https://t…
The problem with that reasoning is that nearly every language with static typing also has some kind of type inference. You'll just wind up with a bunch of autos/vars.
Nearly all the type errors I see are things like
var foo = "Hello World";
bar = foo + 10;