Inspired by @h3ll, this is a combination of current and former coworkers:

Awkward Wizard:
This guy has the social skills of a microwaved dog turd. He is a genius, but working with him is about as uncomfortable as sticking a grill skewer in your eye and twisting it repeatedly until close of business. He laughs at inappropriate times, and every time he does, an unborn child tears its own ears off. He explains things in a way that only himself and Satan understand, then talks to you like you're a child when you don't follow his logic. He is the guy you hide when the CEO is around. His code is immaculate.

Backstab McGillacutty:
This bowl of bile is the son of a bitch that takes credit for everybody else's work. When you do something good, he was miraculously involved, but when you mess up, this twat is the dicknose that brings it up in retrospective and calls you out by name to the boss. You can usually find these guys talking shit about the CTO, until the boss quits. Then they buddy up with the CTO and become a Joel Osteen-esque evangelist for everything the CTO wants in a shitty, underhanded attempt to climb the ladder. Fuck this guy.

Professor Fuckwaffle:
This coworker used to teach Computer Science classes. Their resume is amazing, and they can speak to the most complex of design principles. This is the shitstain that you hire because of their skill and knowledge only to find out that ol' fuckwaffle can't apply the shit they spout to save their wretched lives. You'll spend more time listening to fuckwaffle lecture than you will reviewing their code (because they cant fucking write any!) You know the saying, those who can, do, and those who can't, teach? Yeah, that shit was written for Fuckwaffle.

Last but not least:
Scrumdumb:
This guy isn't even a coder. This guy is worse than the the scum you pour out of the bottom of a slow-cooker that you forgot to wash last time you made chicken. He's a non-technical PM. You know the type, right? He usually says "cloud infrastructure," "paradigm," "algorithm," "SDLC," etc but has no grasp of any of them. He often opens his dumpster to spout off something like "You can just create a new class for that" while talking about HTML. I won't waste any more breath on Scrumdumb, he already creates enough work for me.

Sometime in mid 2013 or 2014 as a junior dev I woke up to a call from my company's CEO. He informed me that the legacy system they use for order processing is down nationwide that nobody can add new orders until it's fixed and that I needed to fix it. I had been working there 6 months and was hired along with a senior dev to begin developing a web app to replace this legacy system. The senior dev had left the company two weeks earlier for a better offer so it was put on me to figure it out. I was very frank with the CEO and told him I didn't know if I could fix it and suggested he try to call the company they hired to create it. I didn't even know where the source code was let alone what the design paradigm was or whether or not there was any documentation. He said he would try figuring out who created it and give them a call and asked "As a developer you shouldn't you be able to fix this?" I just told him it wasn't that simple and left it at that.

I get to work and the CEO has discovered that the company who created the software no longer exists and I tell him he may need to find a company to consult on this if I can find the source code and if I can't find the code he might be screwed.
I found the source code in a random IT shared folder there is no source control, no documentation, no unit tests, no test environment, and it looks like nobody had touched it since 2005 or about 8 years.

Despite being completely unfamiliar with the code and the design paradigm I was able to figure out that they were validating customer addresses against an old Google geocoding API that was shutdown the day before and the lack of response was killing the application. I fixed the issue and warned the CEO before deployment that I wasn't able to test but he said to go ahead and thankfully all went well.

What fascinates me the most about the industry we work in, is the disruptive and transformative nature of ideas the come out every day.

The technology we use augmented with the software we build have the capability to disrupt and shift the existing paradigm of absolutely any industry today. The solution we construct changes the way in which an industry functions, and brings the horizon closer while making the ocean wider.

So does our capability to design and transform the existing landscape with the ability to visualise the many dimensions of a problem that are otherwise overlooked by others.

I had one of the best feelings today when 3 extremely prolific doctors in the Indian opthalmological industry told me how the solution i built could change the way in which they have been working for almost 20 years ... For the best ...

It's just such a great feeling to know every line of code we write , execute and debug would one day disrupt and transform an otherwise traditional landscape.

So hooray to us and the things we invent, because at the end of the day a PC to code and internet for the outreach ( and stackoverflow ofcourse. 😅 ) Is all that's needed to bring about a metamorphosis of conventional thoughts and theories.

4 years ago I made a personal goal/plan to be a full stack developer. Meaning a good understanding of any development between os level code and web/front end user experience.

Over the years this term 'full stack' has been abused greatly and now basically means 'a javascript developer that generally knows what they are talking about'.

So now, devRant collective I ask you. What do you call a developer with good skills in:

- os level code (c, c++ and os apis)
- database level tech (advanced querying and db aglo/modeling)
- software architecture
- application level (workflow and business logic)
- transport level (protocol design and usage)
- front end tech (graphics programming and event driven paradigm)
- user experience

I need to stop treating an OO language as if it were a procedural language.

I have the tendency to turn my code into GOTO spaghetti even though I'm semi-aware that objects exist and that they are distinct.
I still have to get used to this paradigm.

My Java professor always swore by the Plato paradigm, i.e.:
""Platonism" and its theory of Forms (or theory of Ideas) denies the reality of the material world, considering it only an image or copy of the real world.
According to this theory of Forms there are at least two worlds: the apparent world of concrete objects, grasped by the senses, which constantly changes, and an unchanging and unseen world of Forms or abstract objects, grasped by pure reason (λογική). which ground what is apparent." (wikipedia)

Thinking in objects, abstractions and metaphysics is not something I haven't done before (I've practiced it during Sociology and Ethics with the whole Pascal Leibniz, Newton and DesCartes approach) but it's certainly not easy.

Then there was my cool Programming 201 professor who said: "Don't worry man, just read those great UML, Program Design and GOF books and it will all become easy, like a story. It'll all make sense.
I mean, I've graduated, I've passed my Software Engineering I, II and III (hard as hell) but since I haven't focused on those theories and practices anymore, I've lost my touch.

It's definitely not easy for a novice programmer to transition between paradigms..

So we started a new Unity video game project for mobile in June 2021. Hooray!

Being a mobile project, one of the earliest things we think about is scaling the interface across all sorts of device screen resolutions and aspect ratios, right? Well, to preemptively solve this problem early on, I decided to letterbox the game view - just choose one aspect ratio for the game and pad black bars to the sides of the screen. Simple, solves the game's world space problem without trying too hard, and it automatically adapts to Android's split-screen mode.

I showed the early builds to management as well as game design team and they gave me some general nods. Sounds like green light ahead. I spent the next few months building the game logic and scale the UI around a consistent letterboxed game view. If you had experience scaling Unity UI to a letterboxed area, you should already knew that it takes a whole paradigm of its own that's kinda hard to break out of, but the fact that it stays consistent across all screen aspect ratios is so worth it. Regardless, the biggeer benefit of letterboxing is simpler world space setup. You don't worry about whether this particular area will be overflowed horizontally or vertically in a particular device or not. You have a 9:16 window to view the world through, nothing needs to move at runtime and that's about it.

Fast-forward to early September 2021 and 40+ builds later, the GD started having concern that the playing area is not filling up his phone screen and that the letterboxes are bothering him. He wants to get rid of the letterboxes and wants the game world as well as UI to fill up his screen.

Yes. After 40+ builds, for all of which the letterbox was present, nobody in the project raised a concern about the letterbox. It's only NOW that they all of the sudden side with the GD and demand the removal of the letterbox. I feel like almost half of my effort on this game has been wasted. These clueless guys didn't spend one second looking at the early builds thinking of the possibility that the black bars at the top and bottom of their phone screens (which I repeat: has been around since the very first build) is gonna bother them? Somebody must be playing a cruel joke at this company. They had all the chances to bring this up as a potential issue and TODAY is the first time I hear of it.

See, designers. You waste our time and your time by doing this kind of thing. Please raise your issues early. Complain to us ASAP. If you wait for so long before raising an issue that has been in-your-face the whole time, I can't fault any developer for assuming you're trying to play a long prank. I can tell designers right now: it's not funny.

"Abstract all the things!"

Theres so much fucking abstraction and so many different ways to abstract shit that I don't fucking know how anything works anymore.

Fuck this

Start with simple projects then keep improving it until you reach the depth level that you want.

I used to learn a new language/technology every month, I did that all this year until now, I learned 3 new languages, 2 new databases, 1 new paradigm, so many frameworks and methodologies and design patterns applying in real world projects !

I wrote my first proper promise today

I'm building a State-driven, ajax fed Order/Invoice creation UI which Sales Reps use to place purchases for customers over the phone. The backend is a mutated PHP OSCommerce catalog which I've been making strides in refactoring towards OOP/eliminating spahgetti code and the need for a massive bootstrapper file which includes a ton of nonsense (I started by isolating the session and several crucial classes dealing with currency, language and the cart)

I'm using raw JS and jquery with copious reorganization.

I like state driven design, so I write all my data objects as classes using a base class with a simple attribute setter, and then extend the class and define it's attributes as an array which is passed to the parent setter in the construct.

I have also populateFromJson method in the parent class which allows me to match the attribute names to database fields in the backend which returns via ajax.

I achieve the state tracking by placing these objects into an array which underscore.js Observe watches, and that triggers methods to update the DOM or other objects.

Sure, I could do this in react but
1) It's in an admin area where the sales reps using it have to use edge/chrome/Firefox
2) I'm still climbing the react learning curve, so I can rapid prototype in jquery faster instead of getting hung up on something I don't understand
3) said admin area already uses jquery anyway
4) I like a challenge

Implementing promises is quickly turning messy jquery ajax calls into neat organized promise based operations that fit into my state tracking paradigm, so all jquery is responsible for is user interaction events.

The big flaw I want to address is that I'm still making html elements as JS strings to generate inputs/fields into the pseudo-forms.

Can anyone point me in the direction of a library or practice that allows me to generate Dom elements in a template-style manner.

I can't stand when people spend a single day familiarizing themselves with a new technology or concept and then come to the conclusion that's it doesn't work and really the old way is great. Not saying all new things are better. In fact, I'm probably more in favor of tried and true methods than shiny new methods. But one day? Really? That's all it took? In this particular case it's code-first DB development. Again, I'm not a fan myself really. But I have a co-worker who said creating tables and and schemas is much harder using code-first instead of DB first. I mean... Neither are hard. I personally think it's easier for basic things like tables and schemas but either way it's not hard. Now SQL triggers and index's all that fun stuff? Yeah code first is probably more complicated (I'm clearly not a database expert or anything). But a day? Really? You know enough to force a design paradigm on the whole company now? Wtf.

How do you handle error checking? I always feel sad after I add error checking to a code that was beautifully simple and legible before.
It still remains so but instead of each line meaning something it becomes if( call() == -1 ) return -1; or handleError() or whatever.
Same with try catch if the language supports it.
It's awful to look at.
So awful I end up evading it forever.
"Malloc can't fail right? I mean it's theoetically possible but like nah", "File open? I'm not gonna try catch that! It's a tmp file only my program uses come oooon", all these seemingly reasonable arguments cross my head and makes it hard to check the frigging errors. But then I go to sleep and I KNOW my program is not complete. It's intentionally vulnerable. Fuck.
How do you do it? Is there a magic technique or one has to reach dev nirvana to realise certain ugliness and cluttering is necessary for the greater good sometimes and no design pattern or paradigm can make it clean and complete?

Creating a language that takes the immediate feedback and clean design from Eve language and an functional paradigm like Haskell or Purescript

Design in Motion: Real-Time Rendering's Impact on Architecture

Architecture, a discipline that once relied heavily on blueprints, models, and lengthy render times, has undergone a revolutionary transformation in recent years. The advent of real-time rendering technology has fundamentally altered the way architects visualize, present, and interact with their designs. This paradigm shift has not only enhanced the creative process but has also empowered architects to make more informed decisions and create immersive experiences for clients and stakeholders.

Real-time rendering, a technological marvel that harnesses the power of high-performance graphics hardware and advanced software algorithms, allows architects to generate photorealistic visualizations of their designs in a matter of milliseconds. Gone are the days of waiting hours or even days for a single rendering to complete. This acceleration in rendering time has not only expedited the design process but has also encouraged architects to explore multiple design iterations rapidly.

One of the most significant impacts of real-time rendering on architecture is the ability to visualize a design in various lighting conditions and environmental settings. Architects can now instantly switch between daytime and nighttime lighting scenarios, experiment with different materials, and observe how their designs respond to different seasons or weather conditions. This level of dynamic visualization offers insights into how a building's appearance and functionality evolve throughout the day, contributing to more holistic and thoughtful design solutions.

Moreover, real-time rendering has transformed client presentations. Architectural concepts can now be communicated with unprecedented clarity and realism. Clients can virtually walk through spaces, observing intricate details, exploring different angles, and even experiencing the play of light and shadow in real-time. This immersive experience fosters a deeper understanding of the design intent, enabling clients to provide more targeted feedback and make informed decisions.

The impact of real-time rendering on collaboration within architectural teams cannot be overstated. Traditionally, architects and designers would need to wait for a rendering to complete before discussing design changes or improvements. With real-time rendering, team members can make adjustments on the fly, observing the immediate effects of their decisions. This seamless collaboration not only enhances efficiency but also encourages interdisciplinary collaboration as architects, engineers, and other stakeholders can work together in real-time to refine designs.

The integration of virtual reality (VR) and augmented reality (AR) into the architectural workflow is another transformative aspect of real-time rendering. Architects can now create VR environments that allow clients to step inside their designs and explore every nook and cranny. This not only enhances client engagement but also enables architects to identify potential design flaws or spatial issues that might not be apparent in 2D drawings. AR, on the other hand, overlays digital information onto the physical world, facilitating on-site decision-making and construction supervision.

Real-time rendering's impact extends beyond the design phase. It has proven to be a valuable tool for public engagement and community involvement in architectural projects. By creating virtual walkthroughs of proposed structures, architects can offer the public an opportunity to experience the design before construction begins. This transparency fosters a sense of ownership and allows for constructive feedback, contributing to the development of designs that resonate with the community's needs and aspirations.

The environmental implications of real-time rendering are also noteworthy. The ability to visualize designs in various environmental contexts contributes to more sustainable architecture. Architects can assess how natural light interacts with interior spaces, optimizing energy efficiency and reducing the need for artificial lighting during the day.

In conclusion, real-time rendering has ushered in a new era of architectural design, propelling the industry into a realm of dynamic visualization, immersive experiences, and enhanced collaboration. The ability to witness designs in motion, explore different lighting conditions, and interact with virtual environments has redefined how architects approach their craft. From facilitating client presentations to fostering sustainable design solutions, real-time rendering's impact on architecture is profound and multifaceted. As the technology continues to evolve, architects have an unprecedented opportunity to push the boundaries of creativity, efficiency, and sustainability in the built environment.