I agree that the condition is real, but at some point we all have to take responsibility and control of our own careers.
Chances are, you were hired and qualified for the position you hold, with the understanding that there is room to grow within that position, and ideally, that is where you want to be your whole career.
Walking in to work everyday with a complete mastery over everything you do and write is a problem of its own.
For those odd jobs that are somewhere between support and development, calling yourself 'not a real programmer' is a ridiculous mentality to have. Being able to comb through a codebase to insert 5-10 lines of code that fix an issue is a delicate art. I know because I did it for 5 years. Editing black boxes is scary, especially in those instances where tests are scarce.
Embrace your role, and do the best you can. You will be happier for it.
I have a serious issue with not owning and predicting what I'm paid for. For it to work I need a deep and clear trust from the other parties. Which is rarely the case.
In our field, unknowns and chaos are unavoidable. This profession offers a lot to be cynical about.
Establishing clear lines of communication and trust is hard work. As hard as development. People are unpredictable and diverse. It's like writing a different language for every part of the application. The syntax you use to communicate between people changes.
As the world continues its descent into reliance on technology and software, more people are faced directly with generating requirements for developers to implement, and right now the gap between the two world is still rather large. The best way to help close those two worlds in, is not to point a finger at those around us and complain they aren't capable in this environment, it is to help build the bridge so that the person who is in your position next does not have to face those same realities.
It's pretty applicable. And I don't mean just from a techno-skeptical perspective. At the dawn of personal computing, you basically had to be an electrical engineer to get a PC working. So you knew almost everything about your machine. Now, even highly skilled and experienced developers don't know nearly as much about their machine.
This introduces dark corners where bad actors can operate on levels that people either don't know how to monitor or don't even know exist (rootkits, etc.).
And it's not just that. Machine learning is increasingly being trusted to make decisions for us despite being the blackest of all boxes. Decisions like predictive policing (https://www.theverge.com/2018/2/27/17054740/palantir-predict...) that have serious impact on people's lives.
I'm personally less skeptical of technology itself and more skeptical of unqualified people misusing technology (whether that's using machine learning to arrive at bogus conclusions, leaving personal webcams open on the internet, downloading fishy attachments, or anything else).
IMO, including some minimal technical education (like the technological equivalent of home ec) would be a fine start.
I hear you, but every successful technology, even if used correctly and competently, makes the human using it more capable with it, and less capable without it. So in a way it's always a descent. And of course "more capable" includes "more capable of screwing up" as you're basically saying.
Do you have problems in your work place as a result of this?
I do what I get paid for which is generally to solve problems. I get annoyed when people less competent than me choose the solution I should implement, but if they are the ones paying me and they insist on doing it a certain way (after I have explained my opinion) I'll get on and do it anyway. You sound fairly high maintenance in acomparison.
> I agree that the condition is real, but at some point we all have to take responsibility and control of our own careers.
Impostor Syndrome is, or has, become like Asperger's, where every dev thinks they have it. It's a "humblebrag". I honestly tell people I mentor, be confident, but humble. You have this job because you're qualified (or you made yourself qualified), so have confidence in your skills - sit up right, answer questions, take ownership. But also be humble. Don't be afraid to say I don't know, admit you don't know everything about developing.
It's OK To say "I don't know, but I'm doing my best, and if I did, I could answer you."
Maybe this is me being in a bubble or something, but I've never heard a developer (in school or at work) claim to have Aspergers. I've encountered many software developers who have experienced Imposter Syndrome.
It came weirdly into vogue around 2013-2014 I think? It wasn't a massive thing but I do remember it coming up far, far more often than it has before or after.
Eh, I think "imposter syndrome" is a natural consequence of moving into a more selective environment and resetting your baseline estimate of your competence.
If we pretend for a moment that hiring processes are perfect methods for identifying the top X% of candidates objectively, when you are hired by a company that only hires the top 10% of candidates, when you are hired, you instantly go from being better than 90% of your cohort to being average. You might go from being in the 92nd percentile of your old cohort to the 20th percentile of your new cohort.
Sure, it's less stark when hiring processes aren't perfect and hiring criteria are fuzzy and don't oerfectly match the actual job requirements, but any time you go through a selective process it's going to happen a little.
Responsible, experienced engineers should teach newcomers that experiencing self-doubt is part of the process in maturing. I had the fortune to work under a mentor in my original position in this company that wasn't afraid to pull his assigns in to help solve problems he was working on.
Seeing that people of his caliber still acknowledge the value of second opinions and eyes really helped me understand that this business is not about the individual bodies entombed in cube walls, but a complex effort of many teammates.
After I embraced that, I learned where I could, and contributed where I could, and I personally feel much more productive as a member of my new team because of that. Do I still feel like I don't know things? Definitely. I also know that it's a big field and we all won't know everything.
My next goal is to find my way to a leadership position so I can perpetuate this kind of mentality downwards.
to me it seems more of an issue with the environment than the individual. if everyone on a regular basis admitted that the answer to a particular problem isn't coming to them right away - we could avoid the wasted months where a new developer or one thats simply new to this organization spends their life flinching in fear of reprisal.
I think like anything else, there are tiers to this profession. It's fair for someone in this position to call themselves a programmer but I think the OP is doing themselves an injustice by not taking the time to actually learn how to write code. Writings like this are fine, but a point should be made that progressing ones skillset is just as important as getting into the profession.
Otherwise, we support the notion that you don't need to learn how to solve problems to be a "Programmer". Which at its essence, is what a "Programmer" is.
I believe this why "coding interviews" are so controversial. Different people perhaps have a different definition of "programmer".
One person may think a "programmer" should know how to design/implement algorithms, while another would say algorithms are a library implementation issue.
I think coding interviews are fine as long as they aren't insane like what you see a lot these days. We just need a good metric on how to know if the person I'm interviewing can solve general problems, my problems, and has the appetite to grow more.
I still find a big part of coding interviews to be just looking at the quality of someone's code. The problem I've used for years as a take home coding test is not intended to be a test of ability to implement any particularly complex algorithms or to solve unfamiliar problems on the spot but more to see how people write code in the small. Many candidates still don't make a great showing on the basics unfortunately.
> One person may think a "programmer" should know how to design/implement algorithms, while another would say algorithms are a library implementation issue.
The problem is many of us fill both definitions. One minute I could be creating a complex algorithm, the next I could copy/pasting a shell script from stack overflow and neither is necessarily a superset of the other, so which category would I put myself in?
When the only time you have needed to implement a sort algorithm in 15 years is for an interview, then it shouldn't be so controversial an opinion to say its a stupid way to interview. If the job involves writing that sort of algorithm by all means test for it, but the majority of jobs aren't.
The person who cooks and serves you a hotdog at an airport concession stand and Michelin star chef have the same job but they aren't hired to do each other's work.
Being familiar with people in the food industry, I think they'd find it pretty offensive to call someone in the role of a "cook" the same as calling someone a "chef". They have very different meanings.
That does seem like a distinction that the software industry needs to work out. The software developer differences between a cook, a sous chef, and a chef, or Nurse versus an RN versus a Doctor, or a Dental Hygienist versus a DMD, or a paralegal versus a Lawyer.
Not to me. I think the distinction between these titles are silly. Part of programming is architecting applications. There really isn't a way out of it unless you've just been maintaining and patching up existing code your entire life.
I've never seen a formal definition for "Architect" that applies to more than one usage of that term across companies.
Standardization would be the key to it for it to ever be a meaningful distinction.
Similarly, some companies use "Programmer" versus "Engineer", but also there aren't good standards there, and worse that bumps into the expectations in the rest of the business world for what "Engineer" is supposed to mean. (Professional Engineering accreditations and licensures.)
Do we really need to start taking offense to this sort of thing? Does it improve the world in any way? Remember offense is something that you choose to take.
This guy is definitely a programmer ("real" is a silly qualifier imo). However, he might want to reconsider calling himself a systems engineer, when it sounds like he means a sys admin (those are quite different things).
It seems like a significant subset of the developer community, or at least that proportion of that posts online, is hung up on questions of identity as related to their career. E.g. whether they're a programmer or not, whether they're a "real" programmer, whether they're a skilled programmer, why type of programmer they are, and all manner of critique of others answers to these questions and the set of assumptions and prejudices that underlie them.
While I can understand the instincts that drive this phenomenon, does anyone else not think it's all a bit self-absorbed and unnecessary? Like, why is it so important? Is your self-actualisation really so dependent on how you label the activities by which you make money? Bear in mind, to the vast majority of the population, the difference between somebody who "is" a programmer and somebody programs as part of an IT role is a barely existent irrelevance.
I can't speak for anyone else, but I feel like these sort of ontological questions come up a lot when you're a dropout. I had it drilled into my head that if you don't graduate college you will be relegated to a job flipping hamburgers. When I dropped out and managed to achieve roughly the same level of success I would have likely achieved if I had stayed in, it did lead to this feeling of it being "unearned".
Especially at first, I had problems with thinking people were judging me all the time, or didn't take me seriously because I didn't have the letters "B.S." or "B.A." after my name. While this was probably true for some people, I think a vast majority of them seriously did not care that I wasn't qualified on paper, since I could do my job OK.
I don't disagree that these kinds of problems are self-absorbed and the standard definition of a "first world problem", but I found it kind of unavoidable.
At the very least, when job hunting it helps to have useful labels to hang your hat on. Plus the social aspects: it's very hard to answer the question "so what do you do?".
So much of programming is systems analysis happening entirely in one's head. It doesn't seem surprising to me that sometimes these systems analysis processes get distracted and break the fourth wall / start eating on other parts of one's mind.
It seems like an inherent and necessary risk of the profession, even to the extent that maybe someday we'll all look back on and wonder how we ever let programmers exist without serious mental health safety nets in place.
I don't think they're _unimportant_ questions. For just one example, how much money you demand for yourself is directly related to how you value yourself, your value to the company and the value of your work. If you go into those negotiations thinking you're a glorified macro, you're not likely to aim high for what you deserve. If this problem is widespread enough, you have a consistent cultural downward pressure on wages (like basically every other industry suffers).
The _only_ reason developers make as much as they do is that a critical mass of them understands how valuable and difficult their work is, how much their work allows the company to grow and profit, and they ask for what they deserve. If we lose that, we're fucked.
I think it's partly driven by fear - a fear that I myself share in spite of having a degree (or maybe because I have a degree?) that the standards are going to change, the ground is going to shift underneath their feet and they'll find themselves no longer employable as programmers, or as anything else after having nothing except programming in their background.
I try to not call myself a "programmer" for the same reason I try to not put specific languages or platforms on my resume: I don't want to be pigeonholed into a single category. I don't like saying I'm a "Java Engineer" or an "F# programmer", since I want to be free to move around as needed.
Nowadays, usually when people ask what I do, I tell them that I'm an eccentric. This started as a joke, but I honestly feel that it has led to me finding more interesting jobs than I'd have had if I had just said I'm a "programmer".
I usually describe myself as a Software Engineer or Software Architect because of the projects I undertake.
My current job title: Digital Publishing Programmer.
What does that mean: HR processes made it complicated-to-impossible to hire someone for generalist software purposes because it didn't comply with regulated pay schedules within the parent company. In other words, it doesn't really mean anything explicitly.
It isn't worth thinking about this stuff too hard, I promise. If you do good work, that's what matters. Not the identity you come away with as a result of it.
I'm all for not gatekeeping who "real" programmers are. But I feel like we are doing entry-level developers a disservice when we repeat "Learn to code, it's easy FREE MONEY!" It's not. It's a slog. Programming gets very boring sometimes. It takes time.
Anybody else sick of the "Just gluing stuff together" and "I just copy and paste from stackoverflow hahaha" lines? It does not reflect my day-to-day at all. Whenever I hear someone say that, it shows they are early in their career or they are not spending their time learning outside of hacking together code.
More than anything, I find that NOBODY has already done what I'm currently doing, and that online resources other than primary documentation is mostly useless.
Programming is hard because you have to be constantly learning and there is SO MUCH TO LEARN. Not just programming languages, or mathematics, although THAT is a whole mountain to climb in itself. But other skills:
- Communication, both internally and with customers
- Project management, requirements gathering
- Writing good documentation
- Management, mentoring new developers
- Marketing
- Leadership
- Other random software and tools that are NOT programming.
And NONE of this knowledge is going to come without study. We have worked hard to develop technologies and techniques to try and increase the probability of our projects succeeding.
"If you want to be a writer, you must do two things above all others: read a lot and write a lot. There's no way around these two things that I'm aware of, no shortcut." - Stephen King
To be a great ANYTHING means being a great student first. Which means it behooves you to study and learn from the past before charging ahead.
Not to be contrary, but I've never found _programming_ to be boring. What I've found to be the biggest frustration of working as a professional programmer (25 years now) is the expectation that programming, shared by apparently everybody who doesn't program for a living, that programming is easy as long as you've read the "learn programming in 24 hours for dummies" book and put ridiculously unrealistic expectations on anybody who calls themselves a programmer of any level of experience. And, in my experience, protecting that what they're asking for is unreasonable is a waste of breath - "I can't deliver that in that time frame because I still don't even know what it is" is always met with "you have to, figure it out, lowly programmer".
I think the tragedy here, is that people need to view themselves as "programmers" (by which I assume they mean software engineers) to feel valuable. It's like a paramedic / EMT arguing that they are "surgeons" because they perform some surgical procedures in the course of their work; that the bulk of surgery is cutting and stitching. The reality is that there is more to being a surgical doctor than performing surgery, yet a paramedic is still saving lives.
Rather than everyone trying to put themselves in the "programmer" box, and everyone saying "anyone is a programmer". Maybe the technicians need to see / be shown how vital what they do is to the business.
I think a lot of us hire into jobs we 'grow into'.
When you find you've reached your level of incompetence, it's probably time to look for a way to move laterally. But if you find yourself still learning and growing into your role, then you've still got room to move up.
52 comments
[ 4.0 ms ] story [ 133 ms ] threadI agree that the condition is real, but at some point we all have to take responsibility and control of our own careers.
Chances are, you were hired and qualified for the position you hold, with the understanding that there is room to grow within that position, and ideally, that is where you want to be your whole career.
Walking in to work everyday with a complete mastery over everything you do and write is a problem of its own.
For those odd jobs that are somewhere between support and development, calling yourself 'not a real programmer' is a ridiculous mentality to have. Being able to comb through a codebase to insert 5-10 lines of code that fix an issue is a delicate art. I know because I did it for 5 years. Editing black boxes is scary, especially in those instances where tests are scarce.
Embrace your role, and do the best you can. You will be happier for it.
Establishing clear lines of communication and trust is hard work. As hard as development. People are unpredictable and diverse. It's like writing a different language for every part of the application. The syntax you use to communicate between people changes.
As the world continues its descent into reliance on technology and software, more people are faced directly with generating requirements for developers to implement, and right now the gap between the two world is still rather large. The best way to help close those two worlds in, is not to point a finger at those around us and complain they aren't capable in this environment, it is to help build the bridge so that the person who is in your position next does not have to face those same realities.
This introduces dark corners where bad actors can operate on levels that people either don't know how to monitor or don't even know exist (rootkits, etc.).
And it's not just that. Machine learning is increasingly being trusted to make decisions for us despite being the blackest of all boxes. Decisions like predictive policing (https://www.theverge.com/2018/2/27/17054740/palantir-predict...) that have serious impact on people's lives.
I'm personally less skeptical of technology itself and more skeptical of unqualified people misusing technology (whether that's using machine learning to arrive at bogus conclusions, leaving personal webcams open on the internet, downloading fishy attachments, or anything else).
IMO, including some minimal technical education (like the technological equivalent of home ec) would be a fine start.
I do what I get paid for which is generally to solve problems. I get annoyed when people less competent than me choose the solution I should implement, but if they are the ones paying me and they insist on doing it a certain way (after I have explained my opinion) I'll get on and do it anyway. You sound fairly high maintenance in acomparison.
Impostor Syndrome is, or has, become like Asperger's, where every dev thinks they have it. It's a "humblebrag". I honestly tell people I mentor, be confident, but humble. You have this job because you're qualified (or you made yourself qualified), so have confidence in your skills - sit up right, answer questions, take ownership. But also be humble. Don't be afraid to say I don't know, admit you don't know everything about developing.
It's OK To say "I don't know, but I'm doing my best, and if I did, I could answer you."
If we pretend for a moment that hiring processes are perfect methods for identifying the top X% of candidates objectively, when you are hired by a company that only hires the top 10% of candidates, when you are hired, you instantly go from being better than 90% of your cohort to being average. You might go from being in the 92nd percentile of your old cohort to the 20th percentile of your new cohort.
Sure, it's less stark when hiring processes aren't perfect and hiring criteria are fuzzy and don't oerfectly match the actual job requirements, but any time you go through a selective process it's going to happen a little.
Responsible, experienced engineers should teach newcomers that experiencing self-doubt is part of the process in maturing. I had the fortune to work under a mentor in my original position in this company that wasn't afraid to pull his assigns in to help solve problems he was working on.
Seeing that people of his caliber still acknowledge the value of second opinions and eyes really helped me understand that this business is not about the individual bodies entombed in cube walls, but a complex effort of many teammates.
After I embraced that, I learned where I could, and contributed where I could, and I personally feel much more productive as a member of my new team because of that. Do I still feel like I don't know things? Definitely. I also know that it's a big field and we all won't know everything.
My next goal is to find my way to a leadership position so I can perpetuate this kind of mentality downwards.
Sort of. One thing about advancing in your career is that you end up working with people much, much smarter than you. Or at least I do. ;-)
I've felt like a working-class programmer for most of my career and I don't have a problem with that. I frame houses, hang drywall...
I'm a programmer, dammit Jim, not an architect.
Otherwise, we support the notion that you don't need to learn how to solve problems to be a "Programmer". Which at its essence, is what a "Programmer" is.
One person may think a "programmer" should know how to design/implement algorithms, while another would say algorithms are a library implementation issue.
I think coding interviews are fine as long as they aren't insane like what you see a lot these days. We just need a good metric on how to know if the person I'm interviewing can solve general problems, my problems, and has the appetite to grow more.
That's really hard.
The problem is many of us fill both definitions. One minute I could be creating a complex algorithm, the next I could copy/pasting a shell script from stack overflow and neither is necessarily a superset of the other, so which category would I put myself in?
Standardization would be the key to it for it to ever be a meaningful distinction.
Similarly, some companies use "Programmer" versus "Engineer", but also there aren't good standards there, and worse that bumps into the expectations in the rest of the business world for what "Engineer" is supposed to mean. (Professional Engineering accreditations and licensures.)
While I can understand the instincts that drive this phenomenon, does anyone else not think it's all a bit self-absorbed and unnecessary? Like, why is it so important? Is your self-actualisation really so dependent on how you label the activities by which you make money? Bear in mind, to the vast majority of the population, the difference between somebody who "is" a programmer and somebody programs as part of an IT role is a barely existent irrelevance.
Especially at first, I had problems with thinking people were judging me all the time, or didn't take me seriously because I didn't have the letters "B.S." or "B.A." after my name. While this was probably true for some people, I think a vast majority of them seriously did not care that I wasn't qualified on paper, since I could do my job OK.
I don't disagree that these kinds of problems are self-absorbed and the standard definition of a "first world problem", but I found it kind of unavoidable.
It seems like an inherent and necessary risk of the profession, even to the extent that maybe someday we'll all look back on and wonder how we ever let programmers exist without serious mental health safety nets in place.
The _only_ reason developers make as much as they do is that a critical mass of them understands how valuable and difficult their work is, how much their work allows the company to grow and profit, and they ask for what they deserve. If we lose that, we're fucked.
Nowadays, usually when people ask what I do, I tell them that I'm an eccentric. This started as a joke, but I honestly feel that it has led to me finding more interesting jobs than I'd have had if I had just said I'm a "programmer".
I usually describe myself as a Software Engineer or Software Architect because of the projects I undertake.
My current job title: Digital Publishing Programmer.
What does that mean: HR processes made it complicated-to-impossible to hire someone for generalist software purposes because it didn't comply with regulated pay schedules within the parent company. In other words, it doesn't really mean anything explicitly.
Anybody else sick of the "Just gluing stuff together" and "I just copy and paste from stackoverflow hahaha" lines? It does not reflect my day-to-day at all. Whenever I hear someone say that, it shows they are early in their career or they are not spending their time learning outside of hacking together code.
More than anything, I find that NOBODY has already done what I'm currently doing, and that online resources other than primary documentation is mostly useless.
Programming is hard because you have to be constantly learning and there is SO MUCH TO LEARN. Not just programming languages, or mathematics, although THAT is a whole mountain to climb in itself. But other skills:
- Communication, both internally and with customers
- Project management, requirements gathering
- Writing good documentation
- Management, mentoring new developers
- Marketing
- Leadership
- Other random software and tools that are NOT programming.
And NONE of this knowledge is going to come without study. We have worked hard to develop technologies and techniques to try and increase the probability of our projects succeeding.
"If you want to be a writer, you must do two things above all others: read a lot and write a lot. There's no way around these two things that I'm aware of, no shortcut." - Stephen King
To be a great ANYTHING means being a great student first. Which means it behooves you to study and learn from the past before charging ahead.
Not to be contrary, but I've never found _programming_ to be boring. What I've found to be the biggest frustration of working as a professional programmer (25 years now) is the expectation that programming, shared by apparently everybody who doesn't program for a living, that programming is easy as long as you've read the "learn programming in 24 hours for dummies" book and put ridiculously unrealistic expectations on anybody who calls themselves a programmer of any level of experience. And, in my experience, protecting that what they're asking for is unreasonable is a waste of breath - "I can't deliver that in that time frame because I still don't even know what it is" is always met with "you have to, figure it out, lowly programmer".
We need to get past this attitude.
>Anybody else sick of the "Just gluing stuff together" and "I just copy and paste from stackoverflow hahaha" lines?
I cut and paste plenty from Stack overflow. Stack Overflow also rates me as top 5% for Python and Django answers.
I glue stuff together. I try and do it in a way that is elegant and won't cause problems down the line.
Rather than everyone trying to put themselves in the "programmer" box, and everyone saying "anyone is a programmer". Maybe the technicians need to see / be shown how vital what they do is to the business.
When you find you've reached your level of incompetence, it's probably time to look for a way to move laterally. But if you find yourself still learning and growing into your role, then you've still got room to move up.