I just lost faith in the entire management team of the company I'm working for.

Context: A mid sized company with
- a software engineering departmant consisting of several teams working on a variety of products and projects.
- a project management department with a bunch of project managers that mostly don't know shit about software development or technical details of the products created by engineering.

Project management is unhappy about the fact that software engineering practically never sticks to the plan regarding cost, time and function that was made at the very beginning of the project. Oh really? Since when does waterfall project management work well? As such they worked out a great idea how to improve the situation: They're going to implement *Shopfloor Management*!

Ever heared about Shopfloor Management? Probably not, because it is meant for improving repetitive workflows like assembly line work. In a nutshell it works by collecting key figures, detecting deviation in these numbers and performing targeted optimization of identified problem areas. Of course, there is more to Shopfloor Management, but that refers largely to the way the process just described is to be carried out (using visualisation boards, treating the employee well, let them solve the actual problem instead of management, and so on...). In any case, this process is not useful for highly complex and hard-to-predict workflows like software development.

That's like trying to improve a book author's output by measuring lines of text per day and fixing deviations in observed numbers with a wrench.

Why the hell don't they simply implement something proven like Scrum? Probably because they're affraid of losing control, affraid of self managed employees, affraid of the day everybody realizes that certain management layers are useless overhead that don't help in generating value but only bloat.

Fun times ahead!

Hey boss! I optimized our AWS costs by deleting that old CDN we didn't use anymore.

If you're making a game, dont start by thinking about your inventory system. Start by thinking about what you want your player to be able to DO, the cost of those things, and the constraints.

For example, ages of empires didnt have you worrying about unit equipment at all. every villager could do almost any job. while survival games, especially survival horror, like the recent RE remake, severly restrict inventory and stack sizes to make resource managenent more important.

Games like Fallout had list based inventories because lists are cheap, and it allowed a tighter interaction loop. players would loot. go into inventory. close container, onto the next container, keeping the player in the exploration loop longer. neoscav did the opposite *for effect* harkening back to diablo, but taken to the nth degree: *everything*, actions, combat, exploration, character design, all based on an inventory-style grid.
while games like rimworld and dwarf fortress have your inventory represented by zones where items are physically *stored* in stacks on the ground, extending the concept of base management to resource management through physical layout and build optimization.

its important to think about what kind of actions you want players to be able to do, and the kinds of challenges and constraints you want on them at each point of the game and each mechanic they engage in.

other examples, though terrible, include fortnite, where the limitations of competitive play had inventory limited to a resource system and a hotbar. while earlier battle royale and sandboxs games like rust and battleground induced tension by combining loot mechanics and grid inventories with the constant danger of competing players, allowing them to have richer inventory systems at the risk of frusterating players who frequently died while managing their inventory. meanwhile in overwatch, notice how the HUD changes to best represent the abilities of each character.

all in all it is better to stop thinking of inventory systems as a means to an end, and instead as the end representation of desired mechanics, or artificially selected representations for particular effects.

this applies likewise to ui and ux in general. because the design of interface is fundementally about the design of *interactions*, and what you want to enable a user or customer to *do* will ultimately drive those interactions.

If you're working on close to hardware things, make sure you run static analysis, and manually inspect the output of your compiler if you feel something's off - it may be doing something totally different from what you expect, because of optimization and what not. Also, optimizations don't always trigger as expected. Also, sometimes abstractions can cost a fair amount too (C++ std::string c/dtor, for example, dtors in general), more than you'd expect, and in those cases you might want to re-examine your need for them.

Having said all that, also know how to get the compiler to work for you, hand-optimization at the assembly level isn't usually ideal. I've often been surprised by just how well compilers figure out ways to speed up / compactify code, especially when given hints, and it's way better than having a blob of assembly that's totally unmaintainable.

Learnt this from programming MCUs and stuff for hobby/college team/venture, and from messing around with the Haskell compiler and LLVM optimization passes.

When I say I'm in "DevOps" what I really mean is that I'm a full-stack engineer, DBA, system administrator, security engineer, auditor, cloud custodian, cost optimization expert, and everything else that doesn't get its own dedicated staff member here. Pretty much the catch all between developers and customer.

To be honest with you, I’ve never had a bad experience with PHP.

Yes, it’s “dirty” compared to something like Haskell, but it’s not a bad thing. Dirty things usually bring simplicity and allow implementing the intended case super quickly, at the cost of breaking apart at scale. There are no bad tools, there are wrong tools for the job.

Premature optimization is the root of all evil. The more I launch new projects for me/other companies, the more I come to the realization that the vast majority of the projects out there will never see scale. They will be proven non-viable/impractical and deemed obsolete way before they outgrow the $20 VPS they were hosted on.

Sometimes (all the time, really) launching quickly like there is no tomorrow is the most viable business strategy. If (yes, “if”, not “when”) your project outgrows PHP and gets to the point when PHPs abstraction model is the bottleneck, you’ll have the money to rewrite the project in any language out there, trust me.

As someone said on biking subreddit to a person that asked how to buy the newest super-aero helmet, “if the aerodynamics of the old helmet is what holds you back, someone will be sending you the new one for free”.

Learning Pulumi with Python. Not a fan of Py, but I know my way around.

There's a dev cluster. My colleague asked me to modify Pulumi scripts for cost optimization, as the project transitioned to maintenance mode and is no longer needed on daily basis. Since I'm learning, he asked me laughing not to delete/change the static IP and not to delete the cluster.

I'm currently recreating the cluster anew for the third time :)

Gotta say, destroying a cluster is only scary the first time.