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
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "inefficiency"
-
I've caught the efficiency bug.
I recently started a minimum wage job to get my life back in order after a failed 2 year project (post mortem: next time bring more cash for a longer runway)
I've noticed this thing I do at every job, where I see inefficiency and I think "how can I use technology to automate myself out of this job?"
My first ever application was in C++ for college (a BASIC interpreter) and it's been so long I've since forgotten the language.
But after a while every language starts to look like every other language, and you start to wonder if maybe the reason you never seriously went anywhere as a programmer was because you never really were cut out for it.
Code monkey, sure. Programmer? Dunno, maybe I just suffer from imposter syndrome.
So a few years back I worked at a retail chain. Nothing as big as walmart, but they have well over 10k store locations. They had two IBM handscanners per store, old grungy ugly things, and one of these machines would inevitably be broken, lost or in need of upgrade/replacement about once a year, per location. District manager, who I hit it off with, and made a point of building report with, told me they were paying something like $1500 a piece.
After a programming dry spell, I picked up 'coding' with MIT app inventor. Built a 'mostly complete' inventory management app over the course of a month, and waited for the right time.
The day of a big store audit, (and the day before a multi-regional meeting), I made sure I was in-store at the same time as my district manager, so he could 'stumble upon' me working, scanning in and pricing items into the app.
Naturally he asked about it, and I had the numbers, the print outs, and the app itself to show him. He seemed impressed by what amounted to a code monkeys 'non-code' solution for a problem they had.
Long story short, he does what I expected, runs it by the other regionals and middle executives at the meeting, and six months later they had invested in a full blown in house app, cutting IBM out of the mix I presume.
From what I understand they now use the app throughout the entire store chain.
So if you work at IBM, sorry, that contract you lost for handscanners at 10k+ stores? Yeah that was my fault (and MIT app inventor).
They say software is 'eating the world' but it really goes to show, for a lot of 'almost coders' and 'code monkeys' half our problem is dealing with setup and platform boilerplate. I think in the future that a lot of jobs are either going to be created or destroyed thanks to better 'low code' solutions, and it seems to be a big potential future market.
In the mean while I've realized, while working on side projects, that maybe I can do this after all, and taken up Kotlin. I want to do a couple of apps for efficiency and store tracking at my current employer to see if I'm capable and not just an mit app-inventor codemonkey after all.
I'm hoping, by demonstrating what I can do, I can use that as a springboard into an internal programming position at my current gig (which seems to be a company thats moving towards a more tech oriented approach to efficiency and management). Also watching money walk out the door due to inefficiency kinda pisses me off, and the thought of fixing those issues sounds really interesting. At the end of the day I just like learning new technologies, and maybe this is all just an excuse to pick up something new after spending so long on less serious work.
I still have a ways to go, but the prospect of working on B2B, and being able to offer technological solutions to common and recurring business needs excites the hell out of me..as cringy and over-repeated as that may sound.5 -
So the CEO tells me our new release needs to be compliant with new guidelines. I say sure, I draft up a few small changes and send them to my PM. He calls an impromptu meeting with the UI team and I explain my changes. They don't like them. They then proceed to draft and redesign a new UI based on these new requirements, I tell them that they are overthinking everything and remind them of the rules of KISS. 45 minutes of me silently waiting and an entire 4x8 whiteboard of designs, I tell them this is an entire redesign and that we will never make our end of the year deadline. PM goes silent for a minute, then responds "yeah I guess your right, let's just implement your original changes"5
-
I have come to realize that my stress comes from how inefficient my clients use their tech.
I have to stop caring. Is it up? Is it running? Good. That should be where my investment ends.
I shouldn't fear a heart attack or stroke because of some clients' inefficiency.
IT'S JUST SO DAMN HARD. -
It's utterly frustrating to work with someone who has been in the same job for five years but still hasn't bothered to learn the basic tools necessary to do their job effectively. It's like they're stuck in a time warp, refusing to adapt and improve their skills.
How can you possibly expect to be successful in your career if you're not willing to invest time and effort into learning the tools of your trade? It's not rocket science, and these tools are there to make your job easier, not harder.
And what's worse is when these same people complain about their workload, blaming the tools for their inefficiency. Well, guess what? If you took the time to learn how to use them properly, maybe you wouldn't be drowning in work right now.
It's not even about being tech-savvy or a quick learner. It's simply about taking some initiative and responsibility for your own professional development. It's about having the basic level of competency required for your job.
Not to mention that constantly asking for help and guidance on tasks you should be able to handle on your own is not only a waste of your colleagues' time but also reflects poorly on your work ethic and reliability.
So, please, if you've been in the same job for five years and still struggle with basic tools, do yourself and your team a favor and take the time to learn them. It will make everyone's lives easier and improve your chances of success in the long run. Don't stay stagnant and hold yourself back – embrace opportunities to learn and grow. Your career will thank you for it.
The tools in question is Kubernetes and it's directly related to the persons day-to-day work (SWE + SDET mainly), 5 years is more than enough time to learn and adapt to a new toolset, and yet this particular person refuses to invest time into it. It's frustrating, to say the least, but also a disservice to themselves as they are limiting their potential and hindering their own career growth.3 -
If you've ever tried using Go plugins raise your hand.
If you've ever tried doing plugins in Go, raise your hand.
If you think that the following rant will be interesting, raise your hand.
If you raised your hand, press [Read More]:
This is a tale of pain and sorrow, the sorrow of discovering that what could be a wonderful feature is woefully incomplete, and won't be for a very long time...
Go plugins are a cool feature: dynamically load pre-compiled code, and interact with it in a useful and relatively performant way (e.g. for dynamically extending the capabilities of your program). So far it sounds great, I know right?
Now let me list off some issues (in order of me remembering them):
1. You can't unload them (due to some bs about dlopen), so you need to restart the application...
2. They bundle the stdlib like a regular Go binary, despite the fact that they're meant to be dynamic!
3. #2 wouldn't be so bad if they didn't also require identical versions of all dependencies in both binaries (meaning you'd need to vendor the dependencies, and also hope you are using the right Go version).
4. You need to use -trimpath or everything dies...
All in all, they are broken and no one is rushing to fix it (literally, the Go team said they aren't really supporting it currently...).
So what other options are there for making plugins in Go?
There's the Hashicorp method of using RPC, where you have two separate applications one the plugin, one the plugin server, and they communicate over RPC. I don't like it. Why? Because it feels like a hack, it's not really efficient and it carries a fear of a limitation that I don't like...
Then we come to a somewhat more clever approach: using Lua (or any other scripting language), it's well known, it's what everyone uses (at least in games...). But, it simply is too hard to use, all the Go Lua VMs I could find were simply too hard to set up...
Now we come to the most creative option I've seen yet: WASM. Now you ask "WASM!? But that's a web thing, how are you gonna make that work?" Indeed, my son, it is a web thing, but that doesn't mean I can't use it! Someone made a WASM VM for Go, and the pros are that you can use any WASM supporting language (i.e. any/all of them). Problem inefficient, PITA to use, and also suffers from the same issues that were preventing me from using Lua.
Enter Yaegi, a Go interpreter created by the same guys who made (and named) Traefik. Yes, you heard me right, an INTERPRETER (i.e. like python) so while it's not super performant (and possibly suffering from large inefficiency issues), it's very easy to set up, and it means that my plugins can still be written in Go (yay)! However, don't think this method doesn't have its own issues, there's still the problem of effectively abstracting different types of plugins without requiring too much boilerplate (a hard problem that I'm actively working on, commits coming soon). However, this still feels to be the best option.
As you can see, doing plugins in Go is a very hard problem. In the coming weeks (hopefully), I'm going to (attempt to at least) benchmark all the different options, as well as publish a library that should help make using Yaegi based plugins easier. All of this stuff will go (see what I did there 😉) in a nice blog post that better explains the issues and solutions. But until then I have some coding to do...
Have a good night(/day)!14 -
Oh man. When I look for a job after I'm done with school, I need to watch out for those "pay-per-line" bullshit contracts. More lines? Everyone can do that, but it will cause inefficiency just for the money. I could make a fucking Python Hello World program have 100 needed lines if I wanted to, but why would I? More lines = more typing ≠ more work.3
-
I wanna go back to the age where a C program was considered secure and isolated based on its system interface rathe than its speed. I want a future where safety does not imply inefficiency. I hate spectre and I hate that an abstraction as simple and robust as assembly is so leaky that just by exposing it you've pretty much forfeited all your secrets.
And I especially hate that we chose to solve this by locking down everything rather than inventing an abstraction that's a similarly good compile target but better represents CPUs and therefore does not leak.31 -
I'm interning at a mech eng company. Our products have many possible permutations that customers can choose from a spec sheet.
The backend for us mechanical designers is equivalent to copying and pasting the same code (with slight changes) into a massive switch statement depending on the program's options. So many near duplicate drawings. Each with individual settings that need to be tweaked and linked to other new duplicates every time a new order comes in.
As a programmer it drives me absolute bonkers! I've talked to them about automating it but "we've just always done it this way, so it probably won't change". Well, as soon as I'm done grinding this current project, I'm hoping to put together a practical demo to change their minds.2 -
Am I the only one that who is forced to implement some funcionality that I know that wont work only to prove to the client that actually wont work as I predicted?
And then implement how I suggested at the begining?5 -
The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.
-Bill Gates