Programmers - what we SAY vs. what we MEAN (
Programmers, what we say vs. what we mean
"What a horrible hack"
By definition, horrible hack can be defined as code that is terribly written ~ yet - against all odds, works. Now this does not mean that the code is good. No, quite the opposite. A horrible hack is code that sucks.
When a developer, programmer, or engineer uses the phrase "What a horrible hack" they are referring to code that they themselves did not write. The code is terrible but does still works and it is a terrible hack because they understand that the solution is "hacked" in. The "solution" solves the feature requirement, but will most definitely break things down the line.
An example of a software engineer implementing a "horrible hack":
Given we have a list of people ordered alphabetically.
list = ["Amaria", "Bernard", "Cam", "Jimmy", "Kelly", "Len", "Martin"]
Feature Request
"Jimmy" should always be first in our alphabetically ordered list of people
This is an additional constraint on our list - it is no longer purely alphabetically sorted
Proper Solution to Implement Feature
1. We begin of course write our tests because as good developers we neeevveerr skip testing.
2. We search for jimmy in our list
The list is alphabetically sorted
Alphabetically sorted lists means we have a sorted list which means we can use binary search
We of course know when to utilize binary search so we use it because we have a sorted list
We find the index for Jimmy in O(log n) time - logarithmic time complexity, go binary search.
3. Store the value of jimmy in a local temporary variable.
We make a temporary local variable that stores a copy of jimmy.
We instantiate a single variable called temporaryJimmy
Using the index we found in step 2 we access Jimmy in O(1) time otherwise known as constant
time complexity. Duh, am I right?
We copy Jimmy into the our temporaryJimmy variable. (Space complexity of O(1) - we only store one new variable irreguardless of the function input size. n
4. We delete Jimmy from our array
Array delete - O(n) linear time complexity, still pretty solid
5. Finally we Insert temporaryJimmy to the front of our array (shift in an item)
We shift temporaryJimmy into the front of our array - Array Insert - O(n), aka linear time complexity.
6. We confirm our code is passing
7. We collaborate via a code review set up by you because we're inspired.
8. We document our changes using pretty colors and icons.
9. We do all the stuff to run the code through our code deployment life cycle
10. We successfully our feature request ticket. The right way.
"Horrible Hack" Solution.
list[0] = "Jimmy"
Why is it a horrible hack?
we over write a person in our list of people
we still have another Jimmy some where in our list of people
we didn't take into account testing, documentation, code reviews, etc...
But hey. The time and space complexity is technically faster so there's that...
The horrible hack solves the feature request, but at the end of the day it is terrible code. If a developer calls your code a "terrible hack" your best course of action to rebuttal their offensive remark by shifting the context of the code's goal.
Your response to being told you implemented a "Terrible Hack" should always be to defensively exclaim that it is simply a "Temporary work around".
A "Horrible Hack" is terrible code someone else wrote. A "Temporary work around" is terrible code that you wrote. Much like survival, you must be first to the punch. Yes, a "temporary work around" is a "horrible hack". No, there quite literally is no difference between the two when it come's to software developer and programming slang - however, setting the context of "temporary work around" will always be your go to move in hopes of confusing the product manager's, scrum masters, and operational business personal. "Temporary work around will not 'save face' with other software engineers. We know you just implemented a horrible hack, we're engineers like you." But, we have enough experience to know that not every hill is ours to die on.
If you create a "Horrible Hack" change the conversational context and thus opinion by not giving your self up. You're "Horrible Hack's" are "Temporary work arounds". Other developer's horrible hacks are just that - horrible hacks. This is how the system of code quality circulates. This is how progression is made.
This has been a simplified lesson on "What programmer's say vs. what programmer's mean".
https://cleancode.studio
Looking for non-satirical, real world, clean code advice?
Check out this post! https://cleancode.studio/clean-code
#WhatProgrammersSayVsWhatProgrammersMean #HorribleHack #TemporaryWorkAround #KnowTheDifference #programmers what we say vs what we mean #code #developer #software #engineer #computerscience #dev #programming #softwareengineerlife #developertips
![This is what clean code looks like [tell-tale signs of clean code] (#Shorts)](https://pics.providosiki.ru/watch/7UuQcDs86Uo)
