Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "compiler-failure"
-
Java teacher writes code on blackboard in comp lab
He tells us to try it out at our workstations.
We do. The code does work. We tell him.
He says: "There is something wrong with your compiler..."
Question is...we were around 30 students. Can all our compilers not work if we had used the lab before and the code we run worked clean??!?!?!?
We were flabbergasted2 -
Here comes lots of random pieces of advice...
Ain't no shortcuts.
Be prepared, becoming a good programmer (there are lots of shitty programmers, not so many good ones) takes lots of pain, frustration, and failure. It's going to suck for awhile. There will be false starts. At some point you will question whether you are cut out for it or not. Embrace the struggle -- if you aren't failing, you aren't learning.
Remember that in 2021 being a programmer is just as much (maybe even moreso) about picking up new things on the fly as it is about your crystalized knowledge. I don't want someone who has all the core features of some language memorized, I want someone who can learn new things quickly. Everything is open book all the time. I have to look up pretty basic stuff all the time, it's just that it takes me like twelve seconds to look it up and digest it.
Build, build, build, build, build. At least while you are learning, you should always be working on a project. Don't worry about how big the project is, small is fine.
Remember that programming is a tool, not the end goal in and of itself. Nobody gives a shit how good a carpenter is at using some specialized saw, they care about what the carpenter can build with that specialized saw.
Plan your build. This is a VERY important part of the process that newer devs/programmers like to skip. You are always free to change the plan, but you should have a plan going on. Don't store your plan in your head. If you plan exists only in your head you are doing it wrong. Write that shit down! If you create a solid development process, the cognitive overhead for any project goes way down.
Don't fall into the trap of comparing yourself to others, especially to the experts you are learning from. They are good because they have done the thing that you are struggling with at least a thousand times.
Don't fall into the trap of comparing yourself today to yourself yesterday. This will make it seem like you haven't learned anything and aren't on the move. Compare yourself to yourself last week, last month, last year.
Have experienced programmers review your code. Don't be afraid to ask, most of us really really enjoy this (if it makes you feel any better about the "inconvenience", it will take a mid-level waaaaay less time to review your code that it took for you to write it, and a senior dev even less time than that). You will hate it, it will suck having someone seem like they are just ripping your code apart, but it will make you so much better so much faster than just relying on your own internal knowledge.
When you start to be able to put the pieces together, stay humble. I've seen countless devs with a year of experience start to get a big head and talk like they know shit. Don't keep your mouth closed, but as a newer dev if you are talking noise instead of asking questions there is no way I will think you are ready to have the Jr./Associate/Whatever removed from your title.
Don't ever. Ever. Ever. Criticize someone else's preferred tools. Tooling is so far down the list of what makes a good programmer. This is another thing newer devs have a tendency to do, thinking that their tool chain is the only way to do it. Definitely recommend to people alternatives to check out. A senior dev using Notepad++, a terminal window, and a compiler from 1977 is probably better than you are with the newest shiniest IDE.
Don't be a dick about terminology/vocabulary. Different words mean different things to different people in different organizations. If what you call GNU/Linux somebody else just calls Linux, let it go man! You understand what they mean, and if you don't it's your job to figure out what they mean, not tell them the right way to say it.
One analogy I like to make is that becoming a programmer is a lot like becoming a chef. You don't become a chef by following recipes (i.e. just following tutorials and walk-throughs). You become a chef by learning about different ingredients, learning about different cooking techniques, learning about different styles of cuisine, and (this is the important part), learning how to put together ingredients, techniques, and cuisines in ways that no one has ever showed you about before. -
Figure I can simplify the code if I have the compiler handle *some* of the register allocation.
Eh? What do you mean "NP-hard"? Dafuq's an ENN-PEE?
**frantically reads wiki**
I can proudly say that I understood absolutely nothing; CS stands for cocksucker or rather abysmal failure at the most basic forms of communication, I don't just sit here all day expecting you to flawlessly prove my point with every swallow of breath you draw, yet here we are.
Perhaps one factor involved in producing the generalized cluelessness of my colleagues, I mean their "imposter s*ndrome", has a bit to do with how fucking thick you've formulated this glorified bollocks you call theory. Were not for your incompetence, arcane crackheads like me would simply __not__ be capable of rising to the top of this field entirely via determination and a big salami, therefore I owe you both a debt of gratitude as well as every last word and sign of total disrespect.
As interesting as the study of computational complexity can be, if done correctly that is, you idiots are stuck in a mathematician's abstract mindset in a field entirely devoted to application of ideas rather than *just* the ideas themselves.
To answer my own question, it means there's no known efficient solution. That's it. The part about nondeterministic polynomial convolution of an irreductible rectosigmoid junction can apparently be skipped altogether. Anyway, I solved the problem with the computational equivalent of pizza sticks while you were out in the field mentally jacking off to λ.
Lecture is over, now go clean up the ethereal masturbatory residue if you will, I have mystical el Khwarizmi type-shit to solve via further clubbing of abstraction through liverwurst bologna of immense proportions. ^D3