I feel like a fraud and that’s a good thing
medium.com
medium.com
It made me think about how some tools, libraries, or frameworks seem to prefer to use buzzwords or neologisms to make simple things seem complicated. As though by obfusticating the problem domain, they can make their solution seem that much more magnificent. As though the docs should make you feel stupid.
And the reason they do this is because in our industry, it works. Things often seem impressive to the degree that they seem complicated. People are "advertising" their stuff by making it seem like a special snowflake instead of a simple thing.
Far be it from me to blame people for doing something that works. But there is a bit of an echo chamber, especially in this forum, where developers -- developers, not marketers, not "suits" -- prefer to use buzzwords over plain language, and they would rather you think they did something complicated than something simple or something solid.
Some time ago, an upgrade to Foundation framework required NodeJS and Ruby 1.9+, a version not preinstalled on my Mac. OK, at the time I knew nothing about NodeJS and have never used Ruby, how hard could it be? 5-10 minutes max?
- NodeJS installed fine, but I had to use "sudo" to install modules or I'd see errors
- Googled... many people used "nvm". I installed nvm, had some issues, but in the end all worked fine
- Next, Ruby. "rvm" is popular, I'll try that.
- rvm installation failed with a cryptic error message, Googled message...
- I need to install "command line tools" which come with Xcode
- I don't have Xcode and apparently it's several GB, after an hour or more I finished downloading it.
- I had to open Xcode, find some random preferences panel and click some button to install "command line tools"
- rvm installation still did not work, Googled.... many people use Homebrew
- installed Homebrew, ruby 2.x installed (with strange warnings) but showed 2.x in the console
- Foundation tools did not work
- Googled how to uninstall Homebrew, found some random "gist" script some guy made which does scary things on my system
- Tried installing rvm again, and for a reason unknown to me, it was successful!
- Foundation tools still did not work
- Didn't notice, last two line of rvm installation required me to copy/paste two lines into the shell.
Great, now I can use Foundation in my Grails project that has nothing to do with Ruby or NodeJS. This whole process took ~6 hours, half of the time I spent just googling error messages.More recently, I couldn't figure out how to properly package/bundle my React app into a single minified JS file with browserify. The docs linked to a nice simple template:
https://github.com/petehunt/react-browserify-template
The package.json has a few useful commands in the "scripts" section:
"scripts": {
"start": ...
"build": ...
}
"npm start" works fine, so why isn't "npm build" working!?!? I posted on stackoverflow and got no answers. Ten days later I figured it out. Knowing very little about npm I had no idea "npm start" was a shortcut for "npm run-script start" and thus I needed to do "npm run-script build".Somehow I feel better knowing there's at least one another person on the planet losing 6 hours at time for `just installing X piece of tech`.
Worst thing I had to figure out was that the node package on raspbian is originally related to some radio thing and I had to symlink node-js to node to make it work.
It just goes to show the utter most importance of good documentation. Good as in `human readable` not `logically correct sentences à la man GIT`.
You've got 3 frameworks installed, each based on a different programming language, using bits from each, whereas each framework was intended to be a "full-stack" product used standalone. If anything, the real issue is with Grails not supporting Foundation.
The last three Perl codebases I have worked with were overly complicated when I started and had major sections that only a few people had the domain knowledge to touch. With one of those, I became the domain knowledge expert (financial accounting). But the other two I just haven't had time to do that. For example, I am not a quantitative finance guy and I would have to learn that field (and the other is even more specialized).
But what I have learned to do is be guided by a few principles:
1. I much prefer to work with people smarter than me.
2. I try to be good at the little things everyone else ignores ("is this really the right way to handle exceptions?" "Are these functions really written with testability in mind?").
A big problem of course is that codebases don't just fall from the sky, nice and sleek. They are built up over time and entropy within them slowly grows. What starts out as simple get tweaked and made a little more complicated, then again and again until it is a monster you can hardly touch safely.
Simple, beautiful code is darned hard to write and I haven't yet met anyone who succeeds at that all the time (I know I don't). But one can hope with feedback from outside eyes, and a willingness to watch and rewrite over time, that it may eventually get there.
The funny thing is, you don't need to make it sound harder than it is by making up confusing buzzwords, it's already pretty hard!. Especially in the enterprise space.
Imagine if the logistics department, or the aforementioned finance department decided to rebrand their standard practices every few years. It would cause ridiculous levels of confusion amongst the older workers, as they'd assume they needed complete retraining in this new thing. In reality, they probably just need, at maximum, a refresher course to bring their skills up to date with the newer procedures.
If you ever find yourself describing your latest project to a non-IT-savvy friend or relative, then you quickly realise that the buzzwords and branding are unnecessary to get the concept across. The resulting description, unfortunately, can be pretty boring. The other purpose of buzzwords is to make stuff sound much more exciting than it really is...
Sometimes I wish I could be like them. I have this thirst for knowledge and to improve my skills, which is why I'm here reading HN. But it is really overwhelming at times trying to keep up with everything here and at times I can't help but feel inferior to others at times.
I spent several years using GWT and now I'm getting compensated very nicely to work on an multiple ExtJS products. To keep from getting left behind I've toyed with Angular, React, Mithril, mercury, Redis, etc. and my queue of things to learn keeps getting larger and larger (Docker, Vagrant, Sandstorm, most of AWS stack, ...). At this point I probably have at least 200 bookmarks tagged with a generic "Programming" label.
When I'm responsible for the architecture for real systems, I sometimes feel like a fraud. Domain driven design, TDD, CQRS, anemic vs rich domain models, functional vs OO, agile... do I really know what I'm doing? Does anyone know what they're doing?
I recently looked back at some code from some senior level architects I worked with when I was still relatively junior - guys I really respected. Some of those projects had truly awful architecture and I must admit I felt a bit better about myself after seeing that code.
No one knows it all, no one expects you too. You are expected to learn, get up to speed, semi independently and with little direction. It gets easier after you've done it a few times, then it get really old.
I've done that. Now all the technologies I'm using are obsolete. I have Python 2.7 code using FCGI and a MySQL database running on dedicated servers, pushed to the server with Dreamweaver.
Works fine. Needs very little attention. But it's totally obsolete. I need to learn a bunch of new technologies to do the same thing. And they're boring.
New isn't better, especially when it's rehashing the same problem that was solved decades ago.
But I agree that intellectual humility is very important to self-growth.
I've seen third-hand quite a few instances where people are publicly challenged, even harassed, for their not performing their core competency to someone else's (or even everyone's) standards. Recently one public figure announced they were now seeing a therapist, presumably due in part to that overwhelming negative feedback.
You start to wonder if your language/skillset is over the hill, if you really aren't so good at code, heck, maybe YOU are too old in SV years.
Something about the job search process really amplifies this feeling. You never know why they think it isn't a fit - but it's only in searching for a job that you are actually getting some external feedback.
And it's tough.
Even if your skillset is in demand and recruiters are crawling all over each other to make you offers, if the companies you really love aren't among them, it makes you wonder.
It's tough. And it's easier to play the games and engage the behavior the author talks about to get "likes", hacker news upvotes, reddit upvotes, whatever, to let you know your views, your languages, your skills are valid.
It's tough out there.
I disagree however that feeling like a fraud is a good thing (unless you are one) and strongly believe there are much better motivators for studying and being great at something than the fear of others being better than you. I think it is exactly this fear which is at the heart of what enables the emperor's new clothes syndrome to flourish.
Of course, in addition to the hype and buzz there are also a growing amount of authentic great new technologies, but you can't hope to learn them all. The best you can do is know about them so that you'll be able to retrieve them and dive deeper if and when they become relevant to something you need to implement.
All code is energy, and if it's squandered in the wrong places, you get an imbalance. The net effect of engineers getting carried away in a lab is ― you get kids learning how to make their first website thinking that code is some dark art, and some black magic. It's not.
<b>Look ma, no GruntJS</b>
It's rather simple stuff. That said, any time I read the words "Impostor Syndrome", I think of agony aunt sections in newspapers, and open teen diaries, not learning how to style a bullet point with CSS, or improving my craft.• Lack of confidence
• Lack of self-esteem
• Lack of aggressiveness
• Lack of fearlessness
I’m much too humble and too honest. Although these are great personal qualities, and can help when working in groups, in the end they do not get you very far, nor quickly, in business.
Or it just erodes your self confidence until you're committing fixes that miss obvious details which then goes to production and breaks things. Now I'm just stuck in a positive feedback loop and frankly I don't think I'll be able to justify my pay in 6 months.
When you get back, start writing integration tests for your project's "happy path" to catch those kinds of mistakes.
I read your statement earlier and I wanted to get to a keyboard before I responded to it. Dude, whenever a bug makes it into production, it's not just a mistake on your part. It's a mistake on everyone's part. You've been in this company, from what I've gathered, for 6 months. That's not a long time at all. You're still wet behind the ears there; but there's something you need to know about bugs making it to production.
They're not exclusively your failing. Yeah, you wrote the code, and so I get how you feel responsible, but let's just think of all the steps that it had to go through, all the eyes that saw it that didn't see your mistake, remembering that you've only been there 6 months.
1) your code reviewer didn't catch it
2) the QA person didn't catch it when it was tested
If there wasn't a code reviewer, that was a weakness in the process that permitted the mistake to make it there. If there wasn't QA, then that's all the more reason for people to have a close eye on details.But those people didn't see it either, because the bug made it to production. And if they saw it and didn't say anything, then it's their failing for not letting you know about a potential weakness.
You're going to make mistakes, that's why code reviews happen. That's why people test code. We make mistakes, even really dumb ones. They happen all the time.
Don't beat yourself up, man. Just live and learn. You'll still make mistakes, but as you get experience screwing up, you'll make fewer of that particular kind of mistake.
Keep at the craft. We all screw up pretty hard from time to time, that's why we need each other and help each other :)
What a great quote.
Here's a presentation comparing four build systems for Javascript: http://jbavari.github.io/JavascriptBuildSystemShowdown
This is for a language that is deployed as source code. What's wrong with this picture?
There's lots of new, exciting stuff that actually does something, like machine learning or vision processing. That's worth learning. Having to learn another build and deployment system, or worse, being expected to know it to get a job, is just wearing.
In this context, if you see someone who is better than you at the moment, do some work trying to improve yourself and your abilities. The best don't become the best instantaneously - they do it through hard work & maybe a little talent.
My own experience probably has helped me take on the correct perspective in my own career as a developer - I do things purely because I want to do it or improve myself. I don't care about being the most popular/well-known developer or anything like that - it is a job that I happen to like is all. Stars/likes/etc. on GitHub, those don't matter. I create stuff for fun, and if it becomes popular, so be it - I work on open source stuff in the hopes it helps people and to improve my own abilities.
About halfway through the semester I ended up spending more time with this guy and I realized that he really lived and breathed mathematics. I mean, he did all the exercises in every chapter. (Who does that?) He would study for hours and hours before tests. Anyway, it kind of taught me a lesson. If you want to belong, you have to work for it. Nobody's just going to move over to make a space for you. You have to carve a space for yourself.
It's one of the things I struggle most with, besides the relentless self-consciousness that comes from being a 33-yo trying to retrain in a technical profession, is feeling like all that stuff I love has rather minimal crossover with the stuff that might pay the bills ...
I did a talk back in November which included a section on "Imposter Syndrome". The video can be found here; https://james-brooks.uk/staffs-web-meetup-video/
The song "Thank you" by Alanis Morissette comes to mind. She hit it big at a young age. She wisely did not want to suffer the fate that stars like Meatloaf suffered when he hit it big young and then crashed and burned. Overwhelmed by her fame and success, she took a sabbatical and stopped singing. She found her voice again while visiting India, where she was surrounded by throngs of people, none of whom knew here. It was a good antidote to the ills of fame.
It's a big wide world.
I participate here regularly and I spend a lot of time online. Yet, I did not know this person's name. I am not inner circle enough for his name to have caught my attention before.
Also, Alanis Morissette's fame was not undeserved. Neither was Meatloaf's.
But thank you for commenting.
I apologize, but I cannot parse that. Are you saying that the links validate my point of view? Or validates your opinion that I am in error? I just can't make heads nor tails of what that phrasing is supposed to convey.
thx