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
![](/static/devrant/img/pipeless-devrant-banner-white.png)
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "never mess with programmer"
-
I don't know if I'm being pranked or not, but I work with my boss and he has the strangest way of doing things.
- Only use PHP
- Keep error_reporting off (for development), Site cannot function if they are on.
- 20,000 lines of functions in a single file, 50% of which was unused, mostly repeated code that could have been reduced massively.
- Zero Code Comments
- Inconsistent variable names, function names, file names -- I was literally project searching for months to find things.
- There is nothing close to a normalized SQL Database, column ID names can't even stay consistent.
- Every query is done with a mysqli wrapper to use legacy mysql functions.
- Most used function is to escape stirngs
- Type-hinting is too strict for the code.
- Most files packed with Inline CSS, JavaScript and PHP - we don't want to use an external file otherwise we'd have to open two of them.
- Do not use a package manger composer because he doesn't have it installed.. Though I told him it's easy on any platform and I'll explain it.
- He downloads a few composer packages he likes and drag/drop them into random folder.
- Uses $_GET to set values and pass them around like a message contianer.
- One file is 6000 lines which is a giant if statement with somewhere close to 7 levels deep of recursion.
- Never removes his old code that bloats things.
- Has functions from a decade ago he would like to save to use some day. Just regular, plain old, PHP functions.
- Always wants to build things from scratch, and re-using a lot of his code that is honestly a weird way of doing almost everything.
- Using CodeIntel, Mess Detectors, Error Detectors is not good or useful.
- Would not deploy to production through any tool I setup, though I was told to. Instead he wrote bash scripts that still make me nervous.
- Often tells me to make something modern/great (reinventing a wheel) and then ends up saying, "I think I'd do it this way... Referes to his code 5 years ago".
- Using isset() breaks things.
- Tens of thousands of undefined variables exist because arrays are creates like $this[][][] = 5;
- Understanding the naming of functions required me to write several documents.
- I had to use #region tags to find places in the code quicker since a router was about 2000 lines of if else statements.
- I used Todo Bookmark extensions in VSCode to mark and flag everything that's a bug.
- Gets upset if I add anything to .gitignore; I tried to tell him it ignores files we don't want, he is though it deleted them for a while.
- He would rather explain every line of code in a mammoth project that follows no human known patterns, includes files that overwrite global scope variables and wants has me do the documentation.
- Open to ideas but when I bring them up such as - This is what most standards suggest, here's a literal example of exactly what you want but easier - He will passively decide against it and end up working on tedious things not very necessary for project release dates.
- On another project I try to write code but he wants to go over every single nook and cranny and stay on the phone the entire day as I watch his screen and Im trying to code.
I would like us all to do well but I do not consider him a programmer but a script-whippersnapper. I find myself trying to to debate the most basic of things (you shouldnt 777 every file), and I need all kinds of evidence before he will do something about it. We need "security" and all kinds of buzz words but I'm scared to death of this code. After several months its a nice place to work but I am convinced I'm being pranked or my boss has very little idea what he's doing. I've worked in a lot of disasters but nothing like this.
We are building an API, I could use something open source to help with anything from validations, routing, ACL but he ends up reinventing the wheel. I have never worked so slow, hindered and baffled at how I am supposed to build anything - nothing is stable, tested, and rarely logical. I suggested many things but he would rather have small talk and reason his way into using things he made.
I could fhave this project 50% done i a Node API i two weeks, pretty fast in a PHP or Python one, but we for reasons I have no idea would rather go slow and literally "build a framework". Two knuckleheads are going to build a PHP REST framework and compete with tested, tried and true open source tools by tens of millions?
I just wanted to rant because this drives me crazy. I have so much stress my neck and shoulder seems like a nerve is pinched. I don't understand what any of this means. I've never met someone who was wrong about so many things but believed they were right. I just don't know what to say so often on call I just say, 'uhh..'. It's like nothing anyone or any authority says matters, I don't know why he asks anything he's going to do things one way, a hard way, only that he can decipher. He's an owner, he's not worried about job security.13 -
When I was in college OOP was emerging. A lot of the professors were against teaching it as the core. Some younger professors were adamant about it, and also Java fanatics. So after the bell rang, they'd sometimes teach people that wanted to learn it. I stayed after and the professor said that object oriented programming treated things like reality.
My first thought to this was hold up, modeling reality is hard and complicated, why would you want to add that to your programming that's utter madness.
Then he started with a ball example and how some balls in reality are blue, and they can have a bounce action we can express with a method.
My first thought was that this seems a very niche example. It has very little to do with any problems I have yet solved and I felt thinking about it this way would complicate my programs rather than make them simpler.
I looked around the at remnants of my classmates and saw several sitting forward, their eyes lit up and I felt like I was in a cult meeting where the head is trying to make everyone enamored of their personality. Except he wasn't selling himself, he was selling an idea.
I patiently waited it out, wanting there to be something of value in the after the bell lesson. Something I could use to better my own programming ability. It never came.
This same professor would tell us all to read and buy gang of four it would change our lives. It was an expensive hard cover book with a ribbon attached for a bookmark. It was made to look important. I didn't have much money in college but I gave it a shot I bought the book. I remember wrinkling my nose often, reading at it. Feeling like I was still being sold something. But where was the proof. It was all an argument from authority and I didn't think the argument was very good.
I left college thinking the whole thing was silly and would surely go away with time. And then it grew, and grew. It started to be impossible to avoid it. So I'd just use it when I had to and that became more and more often.
I began to doubt myself. Perhaps I was wrong, surely all these people using and loving this paradigm could not be wrong. I took on a 3 year project to dive deep into OOP later in my career. I was already intimately aware of OOP having to have done so much of it. But I caught up on all the latest ideas and practiced them for a the first year. I thought if OOP is so good I should be able to be more productive in years 2 and 3.
It was the most miserable I had ever been as a programmer. Everything took forever to do. There was boilerplate code everywhere. You didn't so much solve problems as stuff abstract ideas that had nothing to do with the problem everywhere and THEN code the actual part of the code that does a task. Even though I was working with an interpreted language they had added a need to compile, for dependency injection. What's next taking the benefit of dynamic typing and forcing typing into it? Oh I see they managed to do that too. At this point why not just use C or C++. It's going to do everything you wanted if you add compiling and typing and do it way faster at run time.
I talked to the client extensively about everything. We both agreed the project was untenable. We moved everything over another 3 years. His business is doing better than ever before now by several metrics. And I can be productive again. My self doubt was over. OOP is a complicated mess that drags down the software industry, little better than snake oil and full of empty promises. Unfortunately it is all some people know.
Now there is a functional movement, a data oriented movement, and things are looking a little brighter. However, no one seems to care for procedural. Functional and procedural are not that different. Functional just tries to put more constraints on the developer. Data oriented is also a lot more sensible, and again pretty close to procedural a lot of the time. It's just odd to me this need to separate from procedural at all. Procedural was very honest. If you're a bad programmer you make bad code. If you're a good programmer you make good code. It seems a lot of this was meant to enforce bad programmers to make good code. I'll tell you what I think though. I think that has never worked. It's just hidden it away in some abstraction and made identifying it harder. Much like the code methodologies themselves do to the code.
Now I'm left with a choice, keep my own business going to work on what I love, shift gears and do what I hate for more money, or pivot careers entirely. I decided after all this to go into data science because what you all are doing to the software industry sickens me. And that's my story. It's one that makes a lot of people defensive or even passive aggressive, to those people I say, try more things. At least then you can be less defensive about your opinion.53 -
Not sure if it's the worst code review but it's a recent one.
We don't really do code reviews where I work unfortunately but my coworker used my framework for the first time (build some nice composer libraries for cmdline projects) and asked if I could make them do autoloading.
He never used namespaces before so I was glad to help him out.
What I saw was a dreadful mess. His project was called "scripts" so good luck picking a namespace...
Than it was all lose functions in the executable file. All those functions are however called by a class in another file (if they where not calling eachother as a cascading mess). That class was extending an abstract class from my library as instructed. However I never imagined my lib being raped like that.
The functions themselves are a horrible mess. Nothing uniform completely different style (our documentation states PSR's should be used).
Parameters counts higher than 5.
Variable names like Object and Dobject (in calling function Dobject is Object but it needs a fresh one.
If statements on parameters that need basically split it in two (should simply be to functions)
If else statement with return of same variable as a single line (sane people use ternary for that)
Note that I said functions. All of it should have been OO and methods. Would have saved at least some of the parameter hell.
I could go on and on. Do I think the programmer is bad yes (does not even grasp interfaces, dep injection, foreach loops). Is this his best work no. He said that for a one of script like this it just has to work. Not going to be used elsewhere. I disagree as it is a few thousand lines of code that others have to read too.2 -
In reply to this:
https://devrant.com/rants/260590/...
As a senior dev for over 13 years, I will break you point by point in the most realistic way, so you don't get in troubles for following internet boring paternal advices.
1) False. Being go-ahead, pro active and prone to learn is a good thing in most places.
This doesn't mean being an entitled asshole, but standing for yourself (don't get put down and used to do shit for others, or it will become the routine) and show good learning and exploration skills will definitely put you under a good light.
2)False. 2 things to check:
a) if the guy over you is an entitled asshole who thinkg you're going to steal his job and will try to sabotage you or not answer acting annoyed, or if it's a cool guy.
Choose wisely your questions and put them all togheter. Don't be that guy that fires questions in crumbles, one every 2 minutes.
Put them togheter and try to work out the obvious and what can be done through google or chatgpt by yourself. Then collect the hard ones for the experienced guy and ask them all at once. He's been put over you to help you.
3) Idiotic. NO.
Working code = good code. It's always been like this.
If you follow this idiotic advice you will annoy everyone.
The thing about renaming variables and crap it's called a standard. Most company will have a document with one if there is a need to follow it.
What remains are common programming conventions that everyone mostly follows.
Else you'll end up getting crazy at all the rules and small conventions and will start to do messy hot spaghetti code filled with syntactic sugar that no one likes, included yourself.
4)LMAO.
This mostly never happens (seniors send to juniors) in real life.
But it happens on the other side (junior code gets reviewed).
He must either be a crap programmer or stopped learning years ago(?)
5) This is absolutely true.
Programming is not a forgiving job if you're not honest.
Covering up mess in programming is mostly impossible, expecially when git and all that stuff with your name on it came out.
Be honest, admit your faults, ask if not sure.
Code is code, if it's wrong it won't work magically and sooner or later it will fire back.
6)Somewhat true, but it all depends on the deadline you're given and the complexity of the logic to be implemented.
If very complex you have to divide an conquer (usually)
7)LMAO, this one might be true for multi billionaire companies with thousand of employees.
Normal companies rarely do that because it's a waste of time. They pass knowledge by word or with concise documentation that later gets explained by seniors or TL's to the devs.
Try following this and as a junior:
1) you will have written shit docs and wasted time
2) you will come up to the devs at the deadline with half of the code done and them saying wtf who told you to do that
8) See? What an oxymoron ahahah
Look at point 3 of this guy than re-read this.
This alone should prove you that I'm right for everything else.
9) Half true.
Watch your ass. You need to understand what you're going to put yourself into.
If it's some unknown deep sea shit, with no documentations whatsoever you will end up with a sore ass and pulling your hair finding crumbles of code that make that unknown thing work.
Believe me and not him.
I have been there. To say one, I've been doing some high level project for using powerful RFID reading antennas for doing large warehouse inventory with high speed (instead of counting manually or scanning pieces, the put rfid tags inside the boxes and pass a scanner between shelves, reading all the inventory).
I had to deal with all the RFID protocol, the math behind radio waves (yes, knowing it will let you configure them more efficently and avoid conflicts), know a whole new SDK from them I've never used again (useless knowledge = time wasted and no resume worthy material for your next job) and so on.
It was a grueling, hair pulling, horrible experience that brought me nothing in return execpt the skill of accepting and embracing the pain of such experiences.
And I can go on with other stories. Horror Stories.
If it's something that is doable but it's complex, hard or just interesting, go for it. Expecially if the tech involved is something marketable.
10) Yes, and you can't stop learning, expecially now that AI will start to cover more and more of our work.4 -
In a country, a long time ago there was a programmer by the name of Alex. He was a programming genius and apart from a few hours of sleep, he was busy developing unique programs for new generation technology firms. Alex was a bachelor and he happily and proudly lived the way he wanted to. He did not have duties, authority over him, bosses to report to, children to take care of, and distractions. He could sit and code for the entire day without getting any break or feeling a bit tired. However, he had no idea that everything in his life was soon going to turn around. Before Marriage: The Bachelor’s Life Alex was the epitome of a modern ‘Play Boy ‘ or every man’s dream. He was fairly dressed, had a classy house, a snazzy car, and a good-paying job. He was in the habit of spending his mornings drinking coffee while browsing through the different coding topics. He comes in the afternoon and spends the evening part of the day with his friends. Life has never been this good. Alex was able to work hard and the more he was innovative, he enjoyed it. It illustrates how a young person would sit for many hours coding at night and not bother about other people around him. He was alone as a bird and as per him, that’s what he wanted to be. He had no peer to tell the truth to, no wife to prepare meals for, no maids to babysit his mess. A man could chow down a pizza for breakfast, lunch, and supper with not even a raised eyebrow from onlookers. He was profiting from living the best life he possibly could. After Marriage: Married Life: Alex & Sarah The climax for Alex is when he marries Sarah on a sunny morning on a fine day. Young people met, and after becoming enamored, started a family and got married to find a new home. Sarah was friendly with people and it was very easy for her to make friends; however, she had little knowledge of technology. Alex had it in his mind that marriage does not change the life you lead and how wrong he was. It was a fairy-tale to have such a perfect life for several days after the marriage. Their nights would be spent in front of the television set with their arms wrapped around each other, eating takeout. Despite this, when the number of days stretched into weeks, and the weeks into months, Alex felt the beginning of a shift in his behavior. The Coding Cave That Transformed into A Home Office Due to the pandemic the coding cave Alex used to have became a home office. Sarah had made up her mind to open her business from home, therefore, she required a home office. Thus, she moved inside the cubicle that Alex had created as his coding cave and left him with no space to code. He now had to code in the living room, because Sarah would incessantly request him to either lower the auditory input of the keys he was typing or to switch off the LCD screen. The Once-Clean Apartment Turns into a Mess Alex was a neat freak, and he adored tidiness, especially in his apartment. But after marriage, his once clean and neat-looking apartment was changed into a dirty one. Although Sarah was not very neat, she used to litter her things anywhere she felt like without being conscious of it. Alex was a programmer and his coding notes were mixed with Sarah's business papers, it irritated him so much. Alex’s to-do list before marriage The to-do list before marriage only comprised coding-related tasks. At marriage, however, he seemed to have developed a longer list of things to do than ever before. Instead of just going to the grocery store to buy some food, Alex seemed to have endless tasks to do mostly around the house. He had to cook for himself, sweep the house, and wash the dishes among other things. This was a new world as far as he was concerned. The Pizza Days Are Over Gone there is no more time for Alex could eat pizza in the morning, afternoon as well and evening. Sarah was very conscious of what she took as food or what her family took as food and therefore ensured that Alex took healthy home-cooked foods. He could not have the pizza anymore but the meals prepared by Sarah were really tasty. Conclusion Therefore from a life before marriage to the life after marriage, it was evident that Alex led two different lives. He went from a playful man with not much responsibility to a man with more responsibilities as a husband and a father. Still, he wouldn’t have it any other way, despite these changes. Later he cherished Sarah and the life they had, and nothing in this world could make him exchange what he had now. Essentially, it was a tricky business being married, but a blessing, and an addition of love, company, and much hilarity too. Therefore, if you are a bachelor reading this, embrace your coding cave and your pizza days because once you utter the words ‘I do,’ all those will be things of the past.But trust me, it's all worth it.1