You are stupid
Stop pretending you're not. We all stupid. We make mistakes, we forgor things, we misuse tools, we believe lies. Just accept it, acknowledge it, admit it. We are stupid, so
Embrace stupidity
Now that you know that you are stupid, act like one. Write code like a dum dum for another dum dum to read it, because this dum dum will be you in an hour, day, week, months or years to come.
Do not assume you will understand your code, you won't. Well, at least not immediately. It will take time, a lot of it, so much that you forgor what you understood in the beginning.
def format(n, *, b = 1024, p = '', s = 'B'):
if not n:
return f'0{s}'
if not isinstance(n, int):
raise TypeError(f'Invalid num type = {type(n)}')
if not isinstance(b, int):
raise TypeError(f'Invalid base type = {type(b)}')
x = '-' if n < 0 else ''
n = abs(n)
try:
m = int(math.floor(math.log(n, b)))
except OverflowError:
m = 99
val = float(n / math.pow(b, m))
if m > 7:
val = f'{val:.0f}' if val.is_integer() else f'{val:.1f}'
return f'{x}{val}{"Y"}{p}{s}'
val = f'{val:.0f}' if val.is_integer() else f'{val:3.1f}'
return f'{x}{val}{["", "K", "M", "G", "T", "P", "E", "Z"][m]}{p}{s}'
This is bad idea, no dum dum will understand, we need to rewrite it.
- Choose meaningful names: what does it format? what the variables hold?
- Add types (if your language is not strictly typed).
- Add comments, but don't overdo it. We are stupid, we forget to change comments, we lie in comments. If you can, avoid comments, but know that you are stupid.
def format_amount(num: int, *, base: int = 1024, prefix: str = '', suffix: str = 'B') -> str:
"""
Humanize any amount to string
format_amount(0) == "0B"
format_amount(1750) == "1.7KB"
format_amount(1234567890) == "1.1GB"
format_amount(2000, base=10, suffix='r') == "2Gr"
:param num: numeric amount
:param base: how much does the step takes (default 1024 as for bytes)
:param prefix: type prefix (default '')
:param suffix: type suffix (default B as for bytes)
:return: Formatted amount string
:raise TypeError:
"""
if not num:
return f'0{suffix}'
if not isinstance(num, int):
raise TypeError(f'Invalid num type = {type(num)}')
if not isinstance(base, int):
raise TypeError(f'Invalid base type = {type(base)}')
sign = '-' if num < 0 else ''
num = abs(num)
try:
magnitude = int(math.floor(math.log(num, base)))
except OverflowError:
magnitude = 99
val = float(num / math.pow(base, magnitude))
if magnitude > 7:
val = f'{val:.0f}' if val.is_integer() else f'{val:.1f}'
return f'{sign}{val}{"Y"}{prefix}{suffix}'
val = f'{val:.0f}' if val.is_integer() else f'{val:3.1f}'
return f'{sign}{val}{["", "K", "M", "G", "T", "P", "E", "Z"][magnitude]}{prefix}{suffix}'
Now I can see what's goin on from the first glance ever years after.
Do not optimize, do not refactor
You are stupid. You can't optimize, you can't write perfect code. Be stupid and just write what you have to.
Feels like code is slow? Don't care, just write it.
You think there should be an abstraction? No you don't. You are stupid.
Evolved monkeys are very very bad at estimates.
- We can't estimate how long the task will take
- We can't estimate how performat the code is
- We can't estimate when abstractions are necessary
- We can't predict how a project will turn.
Do not force it. Do not rush it. Make it "Just Works™". Once you done, you are stupid. Forget optimization, forget refactoring. Make sure you understand what you've done and make sure you will understand it later.
Done? Now is the time to optim.. NO! You are stupid. Write test. Please, do it. Right now. You did? Commit the damn thing.
Once you've done writing stupid code for stupid people that runs the stupid business, once you covered it with tests, you can finally optimize and refactor it. But it doesn't mean you should.
Is is really slow? How slow it is? Do you know? Make sure you really really know how slow things are before optimizing it, otherwise you wouldn't know if it's any better. And remember, you are stupid, so don't guess, write benchmark or whatever.
Do not abstract, unless it's been 20~ish time you've wrote same stuff. Even then you should reconsider it. Most of the times abstractions are simply wrong or change so frequently that you were better of without them.
Do not engineer
Stop pretending that you are an engineer, architect or whatever. You are not. You are stupid monkey. Do not invent things, other less stupid people did everything for you.
- You need to store data? use database, don't try to write some in-house solution to a problem that doesn't exist.
- You need to store files? use storages, don't try to write some in-house solution to a problem that doesn't exist.
- You need to integrate external services? use API wrappers, SDKs, don't try to write some in-house solution to a problem that doesn't exist.
- You need to know that phone number or an email is correct? send message to it and check if it reached, don't try to write some in-house solution to a problem that doesn't exist.
I think you get the gist. Do not solve problems that doesn't exist. Do not look for them. There are no problems, just a task you need to do. Do it and nothing else.
No extras
SOLID? More like STUPID. There's no such thing as clean code, there's no such thing as perfect solution. Only tradeoffs.
Don't just apply every code style or programming pattern you've learned. It won't work.
Use default linter and formatter.
If there isn't one, find 3rd-party "default" that is accepted by community.
- For JavaScript/TypeScript it would be prettier and eslint
- For Python stick to default PEP-8
- For Golang use default go fmt
There is no need in Google Approved Best Recommended Style Guide 9000. You will only hurt yourself. Rely on them only if your team already does.
Write simple stupid and non-pattern code.
You can identify and apply patterns later, just don't force them.
Don't try to add singletons, factories, commands, engines, solid, etc, just because you know them and someone told you to do.
Your code should work and be readable, and stupid. Most of the patterns will come naturally as you write it, or will be obscenely obvious once you're done. If it's not, than it's not the time to add them.
Same thing applies to stupid code. Don't force it's stupidity. KISS (keep it simple, stupid) design pattern doesn't imply that you have to write bad ugly code. Just write naturally as you brain spits ideas on how to complete your task.
Write single-threaded blocking code.
You can't possibly write good multi-threaded code. Not at the beginning, and maybe not even later.
Multi-threaded code is hard. So hard, in fact, that async
exists. And it does for a reason. Just remember, that async is actually single-threaded (except for gorutines and alike, they can and will try to use as many cores as you can give them).
Use your head
Your head is empty. Fill it with some knowledge. Read some articles, watch a video, attend a conference, read a book.
Don't stop learning, because you are stupid. You can't become smart, but you can be less stupid.
Learn every day something new. Repeat what you have learned. Make your brain remember it. But don't just remember.
Analyze. Everything that you read, hear or see - analyze.
- Is it really the case?
- Should I know it, remember it?
- How can I know if it's true?
- How can I prove it's not?
- What is my opinion on it?
- How does this knowledge impact me?
Use your head daily. Do not rely on others. Do not ask others, they are stupid. You are too, but at least using your own brain will make you less so.
Lies, sweet lies
Never ever trust anyone, not me, not even yourself. As I said, we are stupid and we lie.
Sometimes we don't even know when we lie. Some may heard a thing on TV or from parents and believed it's true for the entirety of their lives and now they share it with you. They are your deepest friends, of course they wouldn't lie, right? NO!
They may not understand it, but they can and will lie from time to time. We all do.
Say no
Say no to every stupid idea you, your collegue or your boss has. It is stupid and you know it.
Don't be afraid to say no to stupid stuff. Accepting it for sake of "command spirit" or "humility" is just wrong and will make your life misareble.
I said stupid ideas. It doesn't mean you must decline every task you've been assigned. Just make sure that it's not stupid.
And don't force it. If you have to, you have to. IT is a business, stupid business that stupid humans run. Do the thing if you will lose your job after saying no.
Outro
Most of the things I wrote actually apply to other things in life. Some may say that some of it not even about programming, but it is.
Humans and human interaction is a HUGE part of IT. Humans write code that other Humans use. Humans write articles about programming and stuff. Humans read code, not computer. Computer doesn't read code. It scans it for bits and bytes and stuff.
The most problems in the codebase comes from humans. Improve yourself, improve your skills and remember that you are stupid.
If I forgor something or you think otherwise, do not fret to comment. I am stupid. I lie.
Thanks!
Top comments (2)
Learning about our own cognitive biases really helps in understanding how (poorly) we make decisions. (You are not so smart is a great podcast and books that taught me a lot about the concepts of how badly our brains do what we think they do well, and how we trick ourselves into believing how great we think about ourselves is the truth of reality.
Whenever a junior asks me for my best advice to debug or solve problems, it's always "Check your assumptions!" I'm going to append this to "write down your assumptions and check them"
I didn't know I was that stupid... (⌒_⌒;)