Whether they were once true and now outdated, or were never a thing: What are commonly held beliefs about software development careers that are actually myth?
For further actions, you may consider blocking this person and/or reporting abuse
Whether they were once true and now outdated, or were never a thing: What are commonly held beliefs about software development careers that are actually myth?
For further actions, you may consider blocking this person and/or reporting abuse
Amin I. -
Michelle Sanseverino -
Jasmeet Singh -
Luca Argentieri -
Top comments (63)
βI have a great idea! I just need somebody to make it for me! The idea is the hard part right?β
The idea is the hard part. It took me 30 years to come up with a powerful idea. Programming it has only taken 8 years.
I'd say ideas come often but good ones are hard to come by.
I estimated once that I have a had a quarter million ideas in my life, perhaps two or three good ones. 1) Use endemes to embed meaning in computer programs. 2) History consists of ages which exist in objective reality, each of which is either twice as long or half as long as the previous one. 3) Build a tabletop role playing game where the design of each character is inspired by a verse in the Bible.
I teach software engineering and web development online (mostly to people looking to switch careers or those that have attended bootcamps and are clueless!). A relatively new trend that is a myth IMO is that you must have a portfolio website showcasing your school/bootcamp projects, etc.
I have seen many people get consumed with the notion that you cannot get a job interview if you don't have a portfolio. This isn't true.
At the end of the day, a solid resume is what will land you the interview. Now, this can be in the form of a portfolio website, but it is not a must.
In order to get through the screening rounds, you need to learn your basics well (core CS concepts, languages, etc.) and be able to speak clearly and present yourself. A portfolio will not help there.
I don't agree, in my experience. Either you have experience or you have a huge portfolio, but if you studied a lot and you master a technology but you have non of the above, then all the recruiters will just ignore you.
For a recruiter, 1 year of experience worths like 10 years spent learning, and I discovered it too late
I have to agree with this, though I do have a Github account which acts the same in this context, I still don't have an actual portfolio website showcasing stuff I've built and I've still gotten jobs.
That said, I don't disagree with the notion, it can help and can allow you to show your creativity that you couldn't with say github.
I confess after 4+ years, I couldn't shake this notion. But every single job I have ever landed, my portfolio website isn't "ready" mainly because Im a snob and I can't see myself using a CMS. I keep wanting to write a CMS just for the 100s of challenges it brings. I need professional help!
At least where I went to school all the instructors heavily pushed the idea "you must have a portfolio website". So much so that when projects were graded they were expected to be display as part of your portfolio.
It's all about technical chops and "soft" skills don't matter. Communication is the single most important thing you're going to do. In fact, it's the only thing you're going to do: even the code you write is a long-running dialogue between you and your users, mediated through server processes. Getting good at communicating what you're thinking and doing, whether through talking, writing, presenting, teaching, or otherwise, is difficult. It's also critical if you want to be able to control the course of your career. The image of the lone inscrutable savant writing something So Advanced as to be beyond the ken of mere mortals is poisonous and people who take it as a role model do not have good long-term career prospects.
You have to be passionate about software. People here are going to tend to be passionate, but then dev.to is nothing if not a self-selecting audience. Anyone who wants or expects you to put in extra time because programming is important to you personally is hoping you're a sucker. Do what you have to if you stand to gain from it some other way, but in general: don't work for free. There are employers out there who realize that the time you aren't selling them is worth as much as the time you are.
Couldn't agree more on the importance of soft skills. Developers are often under stress and the combination of IQ and EQ is the way too go. Lack of soft skills like composure and communication will easily break down the team.
I love your communication message. Sometimes it's easy to forget that we're just trying to communicate with our users and make them feel something. I'm getting better at my soft skills and this is part of it :)
I heard some developers still believe tabs are better than spaces... π
It's because they are.
Lingering Spaces and the Problems of Overformatting
Just use standard js
Having a debate about this is useful... A myth... Flip a coin pick one and stick to it π
"Code is self documenting"
Lie!!
The larger the problem that the code resolves, the lesser the intelligibility of the code. Whatever you do, no matter how nice the code you write, this will not change.
I disagree.
Code is self-documented. It's not good, readable or pleasant but a precise one.
Any code that you create without new/changed documentation makes the documentation obsolete. Also documenting something you made might not be correct because your assumptions can be wrong.
Also, automated tests are better documentation that any form of documentation because it actually runs the code (although it might run a different configuration of the code).
You're semantically correct in that code documents itself because you can read the code and therefor know what it does. But that doesn't mean it's good. A car engine is self documenting because you can look at it, therefor anyone who drives can fix an engine. Somewhat contrived but still basically true for your argument I think.
Documentation and comments can and will fall out of date without proper care, but then we should be following the old adage that "comments document the why, not the how".
Yeah, kind what I outlined the "why" in the other response :)
But I don't agree with the engine analogy.
An engine is a unique piece that does one thing and one thing only, so the documentation is never deprecated (for that car model or that specific engine, unless you replace it).
What we typically see in software is someone hooking up a radio to the engine or putting shaders in the windshield while the car is running and stays there (in a web context let's say). It has a more dynamic nature than a pre-made component with standardized interface and replaceable like car parts.
If you have a piece of code that you never touch, sure, documentation is alright. But if you make a fix in the engine with non-standard practices, the car manual will fail you and you'll have to open up the engine anyway. This happens less frequently with cars but almost daily in software.
I agree with you about automated tests, yes. But I've never seen before a self-documented code unless code's job are simple :)
Code is self-documented by definition.
Documentation is an explanation of the code. You can explain the how and why of the code. The "how" is self-evident by the code, but the "why" could be up to interpretation and misleading.
The only reason to document anything should be to explain "why". There's no better way to explain "how" by a readable code and meaningful names, which is not hard but it'll always be consistent.
The "why" could be simple as you pointed out and there's no need for documentation. But also explaining "why" in the code shouldn't be necessary if the code is clean and good (also hard).
Could should be, I think aspiring is fine, expecting is something else altogether.
For me the biggest myth - or fetish - is the distinction between junior and senior developer.
Working for a long time in a job doesn't make you automatically good at it.
Being new on the job doesn't mean, you do not provide value.
Being experienced in one part of your field doesn't make you experienced in another one. It is quite likely, that you are in one part senior and in another part just a junior.
For me there are only developers - each with different personalities, skillsets, talents and potential.
Programming languages are hard
Actually, the languages are not hard but telling the dumb computer what to do is much harder task,
All programming languages are equal
There is a lot that makes them different
Latest framework
People just say "amazing" and forget it.
Programming is about algos
It's not when you are making products, if you make language compilers or library like Lodash then it makes sense but the whole programming is not about it.
Maths
Very few niche branches of programming needs Maths. Most of them don't have anything to do with maths.
I also wanted to post the maths part. Sure, everyone needs some basic maths but not that hyper advanced scientific maths.
I dunno, calc 3 sure came in handy when I wanted to make that sweet ascii art easter egg...
I think the math thing is the biggest one. Because the only time you probably really need to know math. Is my specific case in graphics programming/game dev. Out side of this I really dont ever see the use for higher math.
You need to work long hours to be productive or to succeed in your career. Long hours reduce your output (due to tiredness and lack of focus), and even worse, they encourage the exact wrong attitude for a programmer.
Software is all about automation, so an attitude that encourages long hours is self-sabotage. Productivity is all about solving problems with minimal wasted effort, and trying to reduce your work hours can force you to learn the skills that will make you more productive.
You need to know a specific set of technologies to get a particular job. It certainly helps a lot, but it's definitely not necessary - I've gotten jobs in languages I don't know, and ended up working on things I didn't know how to (image processing, most recently). If you want to get a job with technology you don't know, here's some ideas.
Doing your a job is the same as finding a job. Finding a job is a very different set of skills: marketing yourself, interviewing, writing a resume. Lots of people would make great employees but aren't good at selling themselves. But if you realize they're different skills you can start learning them.
It's like the old joke:
One day a fellow programmer came one hour late to work, said nothing just sat down and started coding. Nobody said anything but everyone was gossiping and giving him bad looks. When he started packing his stuff one hour earlier one of the guys just exploded: "What? You came late and now you're trying to leave earlier? What's wrong with you?!?!". And the guy says: "Sorry, I forgot to tell you I'm on vacation..."
Myth: The software is all about the technology. Fact: It is just as much about the people.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.