The Insecure Developer
dev.to
dev.to
Insecurity itself isn't necessarily a predictor of failure, it depends on what you turn it into.
The less successful guy would also "rather" be himself than the other guy, because he too believes the other guy must be trading his mental health for his productivity.
The successful guy doesn't see it that way. He's happy when he sells a car, and he's happier when he sells more cars. He spends his whole day doing his job, maybe even does research at home. He still enjoys his time with his family, has whatever hobbies he invests his free time in (presumably also more successfully than the other guy). He gets to retire earlier, and he knows it, and that gives him more motivation to be successful.
It is absolutely tragic that people can have the idea that less success is more happy. Some people feel better working harder and you shouldn't have to attribute some opaque negative consequence to them to feel better about the gap.
"Hi, we are not going to pay you, or not very much, but please be at the same level as senior that are already working for us"
I had interns back in the day I had an office (and not working from home) and I always made them work on basic tasks under my supervision. Once I had one woman who was very good, and she worked on a website that ended in production, but most of the time the purpose was to work on internal projects that can be used even if not perfectly polished. You know, stuff you always say you're going to do some day, but you don't.
The advantages were on both sides. They learned real life cases, under my supervision, and I had the tools I didn't.
Disclaimer : I'm French so maybe my example is not relevant.
1) Because desirable internships have more candidate applications than available slots. E.g. Google has 40,000 students wanting an internship but only 1500 slots.[1] With that supply & demand ratio, Google can be selective via difficult coding tests.
2) Even though internships are unpaid, companies evaluate interns to potentially offer permanent employment. If so, a company like Google would want to fill those 1500 slots with "the best" rather than randomly pull from 40000 candidates.
That's how it is at the hot tech companies. Maybe other internship programs outside of tech sectors such as Peace Corps think of interns differently.
[1] https://www.fastcompany.com/1683136/how-to-actually-land-an-...
Code challenges at least have the capability of being very useful. We try and present the type of problems people will have to be solving in that position; if they struggle with it and someone else excels, they have done their job.
Cool, we can finally remove CompSci degrees from job postings.
Having said that, our industry is full of a lot of people who probably are not well suited for the job. Quite a few people look at the 6 figure salaries that you can get in some places in the US and figure it's a cushy way to get rich. Similarly, there are tons of jobs. Everybody is looking.
But here's the catch. "Everybody" is not looking for the average programmer. They are looking for the top 1% of applicants. Anybody who is hiring (i.e. everybody) can verify this. How man CVs do you get a month? How many do you interview? How many do you hire? And even then more than half the time I reckon companies are dissatisfied with the programmers they hire.
So there is actually a huge supply of average programmers that nobody wants. The average programmers aim at the "barely works" bar, and having hurdled it think they are senior programmers. A year or two under their belts, they demand their incredible wages.
At the same time, we all ask ourselves, "How can we protect ourselves from the hordes of untalented hacks knocking at our door?" Whiteboards, puzzles, trick-du-jour. It doesn't matter, because the real problem is what I stated at the top.
Confidence is important because writing good code is very, very difficult. Writing terrible code that barely works is not so difficult. We think we need to protect ourselves, but we don't need binary barriers to protect us from the untalented hacks. We need a better attitude. We need to realise that programming is a skill that takes time and effort to develop.
Some people should not be in this industry -- not because they don't have the chops; but because they don't actually want to put in the time and effort to develop their skills. And it is an overwhelming task. There is so much to learn that you will be drowning in it for years (another reason people put their fingers in the ears and think they are amazing).
So to any "young" programmers (of any age), my advice to you: Have courage. Have confidence. Love what you do because it's a crappy, horrible job if you don't -- no matter how much you get paid. And for those who don't love it... there are lots of jobs that are not programming, but are still in the industry. Quite a lot of them even pay more than programming! Seek them out.
And I think this is the wrong question to have.
"How can we get this new hire up to our standards?" would be better. Problem: once they're up to speed they'll be poached by a competitor. Answer: have real salary upgrades every-time some senior think they're better (not once a year at some review shitshow). Have a good working environment so when one of your people get to a competitor they only have good things to say about you. Then they may come back if things are not as good and may turn some of their new colleagues to send you their resumes.
That's expensive. But that's investing in your workforce. And this should be used not only for your coders but everyone.
This isn't true. The worst developers I know are also the most confident. They think their code is perfect the first time and they don't need to learn any more because they believe they already know everything there is to know. The more confident they are the worse their quality of work is. Luckily they are few and far between.
I'm not saying nobody should have any confidence only that having too much is very detrimental.
> Anybody who is hiring (i.e. everybody)
We aren't hiring.
> more than half the time I reckon companies are dissatisfied with the programmers they hire
Your organization has a problem. We've hired "duds" only a few times. The vast majority of the programmers we have hired have been just fine. Or maybe your expectations are just entirely unrealistic?
>So there is actually a huge supply of average programmers that nobody wants. The average programmers aim at the "barely works" bar, and having hurdled it think they are senior programmers. A year or two under their belts, they demand their incredible wages.
That has not been my experience.
> Love what you do because it's a crappy, horrible job if you don't
You don't have to love it, just not hate it.
(My point was confidence leads to worse code, not better. In fact, "confidence that you can achieve something better" is actually really a lack of confidence.)
You guys (people claiming to be the top global 1%) constantly shift practices, frameworks, and career directions and the only reason you've been so successful at it is because you have a loud voice, and haven't actually put any work into having a cohesive voice about how to train and develop programmer careers. That's why you don't have a golden path for early programming careers -- there is no state of the art to practice at because the field is just chaos with its own direction. It's like rolling the dice to find out which level of Math you'll be taking this year. It could be pre-algebra, or it could be calc III. You don't know because the dice roll represents some fashionable trend in the industry.
If you could actually do this work and answer this question, you'd have a class of useful programmers whom you know will be able to work at a particular level in exchange for a fair wage.
If someone wanted to join this class, then it should be very easy for them to figure out what skills they need and what tests they should take to figure out on their own whether they belong. You can then assess them using similar tests.
In a world of "fake it until you make it", yes, you over-inflate your confidence and appearance of skill. You go until someone completely rejects you because why not? There's no legal repercussions since it's up to the business to do its due diligence. If a business is not happy with its hires, it indicates that they still don't have a good hiring process which gives them the signals you need.
This is something that is near and dear to my heart, so I'm gonna take the opportunity to rant on it a bit. There are quite a few high-paying and fast-moving fields.
Pretty much everything under medicine or law moves is moving on a week-to-week and even day-to-day basis, just like software development. Unlike software development, practitioners in these fields get paid to stay up to date, as part of their day jobs. Lawyers spend a good chunk of their days just reading the latest case reports that are relevant to their field, and boy howdy do our legal systems churn out a lot of reading for them to do.
It's pretty much only in software development that we expect professionals to stay up to date and develop new skills /in their spare time/. There would be a lot more 1% developers out there (or rather, we'd be able to look for the 5% or 10% rather than the 1%) if companies were willing to have their teams spend 4 hours a week training, but no one is willing to do that.
I have guesses on the causes of this industry-wide unwillingness to train, but one thing is for sure: this situation will never resolve itself as long as we honestly and unironically expect members of the field to spend their evenings and weekends learning new algorithms and languages instead of playing with their kids or chilling with their mates.
You know why so many developers settle for mediocrity? Because mediocrity pays the rent, and no one is supporting their path to excellence.
Every verdict is effectively the new rules that lawyers will play by the second that it is made; you could lose the case for not knowing a specific verdict. Medical professionals practice an ancient field that has no interest in gung-ho, extraneous solutions to problems that have already been solved. Software development is one of the few fields where people working it think that learning some oddball, corner-case framework that got its start because the original developer didn't like the code style of some other oddball, corner-case framework is necessarily and always desired by an employer.
Mediocrity is honestly what many customers need. They don't need developers of Herculean strength that can create software of unfathomable complexity, they need a patch to their billing system (or something similarly trivial).
I guess I say all that to say is that people trust lawyers and doctors to be professionals. If they say that they need something, such as time to self-improve -- or the right tools, people listen. The respect their profession bestows upon them gives them an amount of personal clout that most of us don't get by virtue of simply being a dev.
My current theory is it's at least somewhat a result of unions losing power. A union's strategy is to have as many people employed for as long as possible, so it's inherently a long term strategy. The better the company does long term, the better the union members are. I would say unions are the champions of long term strategy for self preservation. If the company goes out of business, all the union members are out of jobs.
Executives are more short term thinkers today. They want quarterly results and they have incentives based on those results (both quarterly and annual) and almost no long term results outside of accumulation of short term incentives. Executives also have the notorious golden parachutes which further shields them from the personal costs of short term thinking. This of course rewards short term thinking rather than long term thinking.
Training is a long term investment, not a short term investment. Short term thinkers want to find someone who will 'hit the ground running,' as I've sure you've heard. Ideally that's what anyone would want. The trouble is, that rarely happens once, much less for an entire team. Short term thinkers can't think outside of that strategy and therefore, we are where we are.
Contrary to that, all older developers I know learn on the job and developed strategies how to make it possible to learn on the job.
Some reasons I can think are people: - don't want any more meetings; - are bad at having a merit driven discussion
Out of curiosity, what roles do you think pay more than programming? Product? PM?
Edit: Forgot about sales! I have a neighbor who works from home in sweat pants but makes insane money in tech sales. Though, he has admitted that the easy stuff is drying up.
IME that's market dependent. One of the reasons I left Singapore was because it was abundantly clear that almost all employers had neither the ability to accurately assess programming talent nor the inclination. They all wanted average drones, cheaper the better.
Moreover, actual competence is routinely confused with the ability to recite algorithms you'll never need to implement, encyclopedic knowledge of obscure APIs or a stint working at a high profile employer.
So yea, in theory most companies want the top 1% of programmers but I'm sure that most wouldn't even recognize them if they saw them.
If you have well defined APIs and modules, then you can actually give one low risk to cheaper junior. If he or she manage to do it great, awesome. If it is too much mess, then senior will redo it when change requests come first time. Most of the time, the module is not perfect, but is useable, junior learned and was useful. That is just one example of how to manage less then super genius super experienced programmers.
It is not so difficult to write good code and some tasks are easier then others. Writing good code boils down to being predictable plus following some rules. Comes easily with experience. But funny thing is, puzzles, whiteboards and tricks do jour have little to do with writing good readable code. They select for people who are good in solving short competition like problems. That is not nearly the same as writing large readable maintenable system. It is useful, in some projects more then in others, but it is still different skill.
That gets us to assigning tasks to people based on their personalities and skills. Someone who is super great in algorithms may write ugly code, someone who writes nice code can have hungups on frustrating tasks and someone learns fast but gets bored easily. Instead of complaining about those three being imperfect, good management assigns them different tasks (or have them choose tasks).
During that time, I haven't met a single soul who would be able to describe what a call stack is and how it works, in rough terms. I don't have a CS degree, but I would imagine that it is something you would learn in the first year - I was tought it in high school (but have actually learned it much later, of course). Best that I got was a description of stack data structure and mumblings about how "variables go there and it's faster than heap". And the amount of bullshit that people came up with, looking completely confident, instead of honestly saying "I don't know it", is mind-boggling.
I remember an old Delphi interview where they asked me what a I already forgot was. I didn't know by name, but once they showed me what they were talking about, I could explain it in depth. They ended up hiring me and I fixed their broken DSS engine and it ended up in a lucrative M&A.
Anyway, standard IQ tests have sections for various skills. Among the ones that are important for programming is abstract thinking and pattern recognition. You should be testing for that rather that word/definition association.
The fact that you include "return addresses" already shows that you understand the concept much better than developers I interviewed.
It's not about knowing the trivia that you can google - it's about knowing that you should google something when you need it.
In what world is it an overwhelming task? Maybe I've landed only at amazing companies but nobody is working the full 8 hour workday. There is time to relax and read random slightly interesting technical things as a break. There are pushes to use slightly interesting technical things in your projects (regardless of how useful it is -- because we need to keep our resumes updated!) and most of the time management will allow it.
The hyperbole from software engineers on how hard this piss easy "profession" is, is just FUD and only serves to keep away people with low confidence issues. In other words, what you are doing is not only keeping potential candidates away, but greatly keeping underprivileged candidates away, and it'd be great if you stopped.
Software engineering given it's current state as the wild west is not a difficult profession in the slightest. It's not law, it's not finance, it's not medicine. We work (relatively) short hours for great benefits and have the ability to work from wherever we want on certain days. Your grades don't matter and you don't need to spend days learning anything other than what's tested in an interview setting or used in production.
Passion is overrated and stupid and it mostly comes from privileged people who had the time to fuck around on the computer all day (and execs wanting to exploit the workforce a bit more) -- not realizing that many people can do what they do given time and mentorship.
There are few other jobs that give you more bang for your buck in terms of effort if you're okay with ~200k/yr being your cap.
It is also a difficult field given that it is one of the few where you probably will have to drop a huge, comfortable skill set every 2-4 years and start over again with a new codebase, different frameworks, and different languages. That does not happen in finance, medicine and law. If it seems easy to you, try jumping into a well established but poorly written project, built using libraries/frameworks you are not super familiar with ;).
I definitely agree with the hours thing though, if you establish yourself at a company you can pull off some pretty amazing work/life balance things.
I did jumped into established projects using libraries/frameworks I was not at all familiar with and liked it. Thankfully companies here are willing to hire like that. It is period when they literally pay you for learning on the job. That is awesome, it is hard to ask for more.
With good fundamentals I think picking up new frameworks and different languages is fairly easy. With the exception of Rust and Haskell, which I'm interested in but never got around to using well, the other languages all seem to come fairly easy after a month or two. There will always be idioms you do not know or fail to remember but that's why there are linters, code reviews, and senior engineers.
It's definitely daunting to jump into poorly written products, and I feel every company has at least a section of their code base that is like this, but that's what good on-boarding and ramping up is for. These are all process issues and not fundamental issues with computer science.
Very few companies I've been at are good at one of these things let alone all of these things. A lot of the time you _are_ slogging at it alone and sometimes you go alone for too long because of ego or lack of confidence. These are all organizational and process issues. Some of it is individual issues too that one must overcome, but making it seem like only the passionate succeed in software engineering like everyone is the top 0.01% of their craft is harmful to the profession as a whole.
My solution to most of these problems is to find a mentor at your company. Anyone who knows what they're doing. I find most people are super nice when you ask questions as long as you are willing to learn and aren't just trying to get them to do something that seems annoying (i.e. asking ops people why your build fails...). I've never met an engineer who _doesn't_ want to talk about how something is designed, the pitfalls, and the hacky work arounds. People like being useful to other people. Let them be useful.
Caveat: I've met a few "legacy" engineers who were hired early and have a negative influence on the direction of the architecture. In companies like these? You can just leave. Everyone wants a good software engineer and as long as you're willing to relocate, you'll land somewhere fine.
Used to feel the same when the Python-crowd harassed me on choosing PHP over Python for webdev. I got my revenge when the python-devs i knew started rewriting their entire projects in ExpressJS/NodeJS due to scaling-related issues and mine still outperform them after 5 years of service.
It means you're a white man and apparently it has become an accepted form of discrimination.
Pretty dumb at the end if you ask me.
Tools change like fashion. What is "hot" today will be nearly frowned on in 5 years and forgotten in a decade or so. In 20 years the fundamentals still matter, the tools, not so much (Pascal? Powerbuilder? Win32 in C?)
A smart developer can learn any tool. Hire for aptitude, not today's toolset.
Interviews can help accommodate this by allowing the candidate to solve a coding test in a language of their choice, while also inquiring about the candidate's learning plans. (Want to make sure they are willing to adapt to the team's tools and not try to force the team to adapt to them!)
I took a job once where the code base was in a FORTRAN-derivative language. I had never used FORTRAN or anything like it. Not a problem. I studied the code. I studied the docs. I figured it out and did the work. I would expect nothing less of any other competent developer.
Another job had a toolchain based on NodeJS on the server-side. Never used NodeJS. Not a problem. Studied the code. Studied the docs. You know the story.
The key skill is a developer's willingness and ability to learn the tools that are desired for the job at hand, and to accept and learn new tools when the time is right.