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
-
The programmer and the interns part 3.
Many of you asked me to keep posting about the interns that I'm responsible for.
I had the intention but never had the time or the energy. Since the interns only kept doing stupid, unthinkable things and just filtering out the good ones is a task of its own.
Time has passed, some interns left us by their choice, others were fired (for obvious reasons). Some stayed loyal and were given permanent positions. New ones joined. I no longer am directly responsible for their wellbeing, yet, somehow I am still their tech-lead and the developer of their tools.
Without further delay,
Case 0:
New guy get's into the internship, has his LinkedIn title set to ‘HTML Technician’.
Didn’t know about the existence of HTML5.
Been building static web pages in the early 2000s. The kind with embedded, inline CSS.
Claims that he is about to finish an engineering degree (sadly I believe him).
Fails the entry level Linux test. Complains about the similarity of the answer options.
Fails the basic web-standars test because "they change so fast, but the foundation is HTML and it's rock-solid!".
Get's caught taking home onions and milk from the kitchen.
Is spotted eating in a restaurant under our offices in his day off. Thrice. He lives a 30 minute drive away and comes here on a bicycle or by bus.
Apparently didn't know that the scrolling wheel on the mouse is clickable.
Said that his PC experience is mostly from his PlayStation (PC = PlayCtation apparently).
Get's fired, says that he'll go to the press. Never does.
Case 1:
Yet another new intern. He seems very eager to learn and work, capable, even charismatic. Has an impressive CV.
Does nothing.
Learns from the "case 0" guy and spends time with him until he is fired.
Comes to work at 8:00 AM and immediately goes to sleep on an office puff. In front of everyone.
Keeps dining alone, without a notice, at different times, for hours. Sometimes brings food into the office and loudly eats it there.
On his evening shifts keeps disappearing for long periods of time. Apparently drinking in the nearby bars and hitting on girls.
Keeps bragging about his success with getting their numbers and rants about those who reject him.
For over a year he fails his final training test and remains a trainee, without the ability to work on a real case.
Not fired yet.
Case 2:
Company retreat. Beautiful, exotic views, warm sun beams, all inclusive package for everyone on a huge half-island.
Simon (he's still with us, now as a true engineer!) brings his MacBook to the beach in order to work and impress all others.
Everybody get's drunk and start throwing huge inflatable balls at each other. One hits his laptop and it immediately is flattened.
Upset Simon is going in circles and ranting about the situation, looking for a solution.
Loses his phone on the beach.
Takes his broken laptop with him while searching for the phone.
Dips the laptop in the river while drunkenly ducking in order to pick a clam.
Case 3:
Still company retreat.
Drunk intern makes out with an employee's drunk wife.
Huge verbal fight. The husband says that he files for a divorce. Intern get's fired.
Case 4:
Still company retreat.
Three interns each take an inflatable swimming mattress and drift with the current. Get found on the other side of the resort three hours later, with red skin and severely dehydrated.
Case 5:
Still company retreat.
The 'informally fired' intern gets drunk again, climbs through a window into a room and makes out with an employee's drunk wife.
Again, gets caught when the husband returns to find a locked door but can see them though the window.
Case 6:
Still company retreat.
We all get ferociously drunk and wander off to the unknown in search of more booze.
Everybody does something stupid and somebody finds Simon's phone.
Simon is lost.
Frenzied horde of drunks is roaming the half-island in search of ethanol and the lost comrade.
Simon's phone get's permanently lost.
Five people step on sea urchins but find that out only hours later and then are unable to walk.
The mob, now including more drunk people who joined voluntarily, finds the sexually active intern making out with the enraged employee's wife yet again.
Surprisingly Simon is found sleeping in a room nearby.24 -
I was hired as a senior software engineer. During handover I found out I'm actually replacing the CTO.
I queried why he was leaving and got a simple "just want a break from working" which I found odd.
Fast forward and now I also just want a break from work, permanently. This place has followed every bad practise and big no-no out there. Every bit of software is a built in house knockoff janky piece of crap that doesn't work and makes people's jobs 5000 times harder.
The UI looks worse than Windows 3.1, absolutely horrendous code formatting, worst database structure I've ever seen.
The mere mention of using a team communication tool results in being yelled at from the CEO whom communicates purely via email, who then gets annoyed when you don't reply because they sent the email to a client instead of you.
We get handed printed out "tickets" to work instead of the so called "amazing in house ticket system" built using PHP 5 and is literally crammed into an 800x600 IFrame. Yes a F$*#ing IFRAME!
It's not like we have an outdated TFS server that has work items we can use...
Why not push for changes you say. I have, many times, tried to suggest better tools. The only approval I've gotten is using PhpStorm. Everything else is shutdown immediately and you get the silent treatment.
The CEO hired me to do a job, then micromanages like crazy. I can't make UI changes, I can't make database changes, why? They insists they know best, but has admitted multiple times to not knowing SQL and literally uses a drag and drop database table builder.
Every page in the webapps we make are crammed into 800x600 iframes with more iframes inside iframes. And every time it's pointed out we need to do something, be it from internal staff or client suggestions, the CEO goes off about how the UI is industry leading and follows standards.. what in the actual f....
Literally holding on by a thread here. Why hire a CTO under the guise of being a senior developer but then reduce the work that can be done down to the level of a junior?
Sure the paycheck is really nice but no job is worth the stress, harassment and incompetent leadership from the CEO.
They've verbally abused people to the point they resign, best part is that was simply because the CEO made serious legal mistakes, was told about it by the employee then blamed it on others.21 -
We have a couple of magazines on the lunch table at work.
There was a paper cloth covering one magazine and one of the Linux engineers lifted it up. This is how it went:
LE: (Linux Engineer) hmm what's under here...? *picks up the cloth*
*a windows magazine appears*
LE: (while putting the cloth back) ew windows, let's keep you hidden!
*other engineers laughing*15 -
Imagine if a structural engineer whose bridge has collapsed and killed several people calls it a feature.
Imagine if that structural engineer made a mistake in the tensile strength of this or that type of bolt and shoved it under the rug as "won't fix".
Imagine that it's you who's relying on that bridge to commute every day. Would you use it, knowing that its QA might not have been very rigorous and could fail at any point in time?
Seriously, you developers have all kinds of fancy stuff like Continuous Integration, Agile development, pipelines, unit testing and some more buzzwords. So why is it that the bridges don't collapse, yet new critical security vulnerabilities caused by bad design, unfixed bugs etc appear every day?
Your actions have consequences. Maybe not for yourself but likely it will have on someone else who's relying on your software. And good QA instead of that whole stupid "move fast and break things" is imperative.
Software developers call themselves the same engineers as the structural engineer and the electrical engineer whose mistakes can kill people. I can't help but be utterly disappointed with the status quo in software development. Don't you carry the title of the engineer with pride? The pride that comes from the responsibility that your application creates?
I wish I'd taken the blue pill. I didn't want to know that software "engineering" was this bad, this insanity-inducing.
But more than anything, it surprises me that the world that relies so much on software hasn't collapsed in some incredible way yet, despite the quality of what's driving it.44 -
Sooo, in my 5 years of high school, I had 5 different IT teachers...
Now, in Italy Highschool goes from 14 to 19 years old, I started programming some days after becoming 13, and "programming" classes begin on the third year, so I had quite a headstart on my classmates...
Now, for the third year, I had an awesome teacher, he noticed I was ahead and... Bored, so he gave me some extra stuff to study, he's the only teacher I've learnt anything from, it was awesome, very stingy with grades, but getting a perfect score with him was so satisfying.
Fourth year, the new guy was old, very old, at least 70, his lessons were just him talking about how programming was when he was young.
But then... During the second half of the fourth year I changed class due to bullying under a teacher's advice, and HE happened...
My new IT teacher, one of the most ignorant, awful people I ever met...
He's literally the reason I only went back to that school once, because another teacher needed help with a course...
One day I made the HUGE mistake to say that his "while(i <10000000000000);" wasn't very efficient for making a delay, because it didn't free the CPU, and since then:
- I never got more than 7 out of 10 at his tests
- He insulted me in front of the whole class
- He sabotaged the oral part of my final exam, shouting that he hated D'Annunzio when he saw he was in the literature part of my thesis (needed him to connect to WW2, and the Memex, that then allowed me to start talking about PCs and programming, my thesis was about the influence of lisp on modern programming languages), loudly chatting with other teachers when I was trying to keep calm (a teacher who knows me quite well, and was there to see my "performance" thought I was going to snap at some point), distracting the english teacher when I was exposing the english part of my thesis and pressuring the commission to give me 99 instead of 100 out of 100
So yeah, he almost made me hate the only thing I'm good at, undervaluing my work and my skills, undervaluing and humiliating me as a person, and I think that if I meet him again I might spit on his face...
So yeah, my biggest "programmer enemy" was a person that then did everything in his power to make my last year and a half of highschool hell
Now I can gladly say that with the help of my tutoring, some of my university colleagues are starting to appreciate programming, and my engineer friends ask for my help when they need advices about their code, and it's giving me motivation to keep doing it and becoming a better programmer to keep up with their expectations4 -
Had an unannounced performance/progress review at work today.
I always get nervous when having those but I know my boss and lead support engineer by now so i got to relaxed mode quite fast.
Then i was getting very cold and started to shake (in combo with the slight nervousness).
That lead to extensive stuttering 😬
Apparently I put my chair right under a fucking ceiling fan thingy in my nervousness.
😅2 -
A room full of mostly old male stressed out engineers sat in chairs, and the presenter said:
"So who watched Judging Amy last night?"
The presenter went on to express her surprise that nobody in the room had seen last night's episode of Judging Amy.... and wasn't going to drop the topic.
The meeting, if it ever had any, now had no chance of going anywhere good.
By the end of the meeting someone would walk out and "retire" shortly there after, and it certainly wasn't going to be the presenter....
Backstory:
The company built on the IBM model of sell pricey custom hardware (granted it worked really well) and sell expensive support contracts wasn't doing as well as it had hoped. Granted it was still doing better than most of its neighboring companies, but it was clear that with the .com bust the days of catered lunches every day were over.
The company had grown fat and everyone knew that while the company had a good enough product(s) to survive, there weren't enough lifeboats for everyone to survive.
In the midst of this an HR department that took up nearly 20% of the office space at HQ felt it needed to justify its existence / expenses.
They decided to do this in the same way they always had, by taking funding from other departments, this time not by simply demanding more direct budgets for themselves.... they decided to impose mandatory 'training' on other departments ... that they would then bill for this training.
When HR got wind that there were some stressed out engineers the solution was, as it always is for HR.... to do more HR stuff:
They decided to take these time starved engineers away from their jobs, and put them in a room with HR for 4 days. Meanwhile the engineer's tasks, deadlines and etc remained the same.
Support got roped into it too, and that's how I ended up there.
It would be difficult to describe the chasm between HR and everyone else at that company. This was an HR department that when they didn't have enough cubes (because of constant remodeling in the HR area under the guise of privacy) sat their extra HR employees next to engineering and were 'upset' that the engineers 'weren't very friendly and all they did was work'.
At one point a meeting to discuss this point of contention was called off for some made up reason or another by someone with a clue.
So there we all sat, our deadlines kept ticking away and this HR team (3 people) stood at the front of the room and were perplexed that none of these mostly older males in this room had seen last night's episode of Judging Amy.
From there the presentation was chaos, because almost the entire thing was based on your knowledge of what happened to poor stressed out Amy ... or something like that.
We were peppered with HR tales of being stressed out and taking a long lunch and feeling better, and this magical thing where the poor HR person went and had a good cry with her boss and her boss magically took more off her plate (a brutal story where the poor HR person was almost moved to tears again).
The lack of apparent sympathy (really nobody said much at all) and lack of seeming understanding from the crowd of engineers that all they should do is take a long lunch, or tell their boss to solve their problems ... seemed to bother the HR folks. They were on edge.
So then they finally asked "What are your stressers?" And they picked the worst possible person they could to ask, Ted.
Ted was old, he prickly, he was the only one who understood the worst ass hell of assembly that had been left behind.
Ted made a mistake, he was honest with folks who couldn't possibly understand what he was saying. "This mandatory class is stressing me out. I have work to do and less time because of this class."
The exchange that followed was kinda horrible and I recall sitting behind Ted trying to be as small as possible as to not be called on. Exactly what everyone said almost doesn't matter.
A pedantic debate between Ted and the HR staff about "mandatory" and "required" followed. I will just sum it up that they were both in the wrong for how they behaved for a good 20 minutes...
Ted walked out, and would later 'retire' that week.
Ted had a history and was no saint. I suspect an email campaign by various folks who recounted the events that day spared ted the 'fired' status and he walked with what eventually would become the severance package status quo.
HR never again held another 'training', most of them would all finally face the axe a few months later after the CEO finally decided that 'customer facing, and product producing' headcount had been reduced enough ... and it was other internal staff's time for that.
The result of the meeting was one less engineer, and everyone else had 4 days less of work done...4 -
I'm talking with this teenager that believes himself an engineer because he built a PC.
He is vehement in telling me that Linux came out in 2007 and it was Valve who developed it for Steam!
They he Googled it to prove me wrong and then... never spoke to me again 😂
I'm an Arch user dude! That's like, just one level under Linus Torvalds!13 -
Like most people I needed some extra cash during uni, so I proceeded to learn CSS + Photoshop (yeah, I know). Followed by PHP and WordPress.
It can be a very shitty platform until you realize that you can stop combining plug-ins from all over the place with dubious code quality and roll your own.
Anyhow I kept at it until I was able to join a niche company doing a quite popular caching plug-in for WP (yeah, W3 Total) when I suddenly became *very* interested in anything and everything performance.
This landed me a very cozy consulting gig in the Nordics - they were using WP for an elephant-traffic website and had run into a myriad of perf issues.
Fixing them and breaking the monolith awarded me with skills in nodejs, linux, asynchronous caching among others.
I was soon in charge with managing the dev boxes for the entire team, and when the main operations dude left, I was promoted to owning the entire platform. (!) Tinkering with Linux for most of my life really came in handy here. (remember Debian potato?)
Used saltstack + aws cloudformation to achieve full parity between all environments. Learned myself some python and all various tips and tricks which in the end amounted to 90% reduction in time-to-first-byte and considerable cost savings.
By the end of the 2yr contract I had turned myself into a fullstack systems engineer and never looked back.
Lawyers not getting along resulted in us having to abandon NewRelic, so I got to learn and deploy the ELK stack as a homegrown replacement, which was super-fun.
Now I work in the engineering effectiveness department of a Swedish fintech unicorn where all languages under the Sun are an option (tho we prefer Python), so the tech stack is unlimited. Infinite tools and technologies, but with strong governing principles and with performance always in mind so as to pick the right tool for the job.
It's like that childhood feeling when you've just dumped a ton of Lego on the floor and are about to build something massive.
I guess the morale here is however disappointed you feel by your current stack - don't. Always strive to make things better, faster, more decoupled, easier to test, etc. and always challenge yourself to go outside the comfort zone.6 -
I finally fucking did it!
I strapped up, strapped in, strapped on... uh wait what?
I finally made the full dedicated switch to linux on my personal computer. Blew away Windows and installed linux. I was able to get about 95% of the games that I actually play on PC to run under a combo of proton/lutris-wine.
I feel like after working in a (primarily) linux shop for almost 2 years now, I've learned enough to be able to actually troubleshoot if/when something goes wonky. I've been a windows/sysadmin type in my career for about 8 years and only touched small bits of linux here and there or for fun little projects like a retropie setup.
But thanks to this gig I'm working at now, as a devops engineer, I've learned so got'damn much about linux and I've been developing scripts/tools that run on linux I figured I could, or better yet 'should', take the full plunge.
So, I've decided that if there's something I absolutely need on Windows that Linux doesn't support, instead of knee-jerking and going back to Windows, I'm going to just setup a VM of windows and daily drive Linux from now on.
Some gfx tweaks for games were definitely necessary, it's still not quite as plug and play as Windows for games, but the fact that it only took like 1.5 hours to sort out all of my games performance is really impressive. Especially, considering none of these games actually supports linux out of the box and Wine/Proton is being used to get them to work.9 -
Before I became a Computer Engineer, (actually, this job is where I learned I loved programming) our manager would pull us into a team motivational meeting.
Except she was a bit of an airhead, so her idea of motivation was having a sing-song and listing our favorite movie quotes.
It was even funnier because there was lots of drama surrounding "how she became our manager," and one of our teammates felt as though she should have gotten the job.
Anyway, none of those were the most ridiculous meeting.
The most ridiculous meeting was when the VP of marketing came to town from Florida to address the brewing drama.
In this meeting, all of my teammates suddenly had the delusion that we were in a union and thought they were protected from getting fired. They threw our manager under the bus. I was the only one who could see that he was there to see if our department was worth saving. They thought they were going to get rid of our manager by shitting on her, but they were just confirming his suspicion that there was a bunch of bullshit going on all around.
So I approached the VP after the meeting, and long story short, I was the only one who got through layoffs with a job offer in Florida a couple weeks later.
I didn't take it, because by that time I decided I wanted to go to school for Computer Engineering.1 -
Once upon a time, one or two jobs ago, a really awesome engineer specced out a distributed search application in response to a business need. This company was managed pretty oldschool and required a ton of paperwork and approvals.
The engineer spent many weeks running tests and optimizing the hell out of this app cluster. It flew, and he had the data to prove it could handle production workloads (think hundreds of terabytes of data being processed every single day)
Part of the way he achieved this was having RAID0 on all of the servers to maximize I/O throughput. He didn't care much about data loss, since the application itself was fault tolerant on a much more granular level.
Management, hearing about this, absolutely flipped their shit and demanded RAID6 instead. This despite the conclusive data that the engineer had that proved RAID6 couldn't keep up.
He more or less got told to STFU.
Even this despite the fact that a RAID restripe would actually take many times longer than rebuilding the failed node from scratch (a process that took about 30 minutes by hand, and could probably be automated to be done in less than five), causing a longer exposure to actual data loss throughout the length of the days-long array rebuild time.
The ill-thought-out requirement added about 50% to the cost of the project (*many* more hard drives now required), beyond the original budget, and the subsequent bureaucratic wrangling resulted in a late product launch.
6 months or so later, after real customers were using this product, the app was buckling under around half of its expected workload. A friend of the engineer suggested to management to try RAID0. Sure enough, that resolved the I/O bottleneck.
This rage-inducing story has a happy ending, though! Said engineer left the company not long after this incident, citing it as a reason for his departure. He was immediately hired by another company, making integer multiples of his prior salary.
The product the company botched the launch of by ignoring his spec? It died a few months later. Maybe the poor customer experience was to blame? Maybe the late launch? Maybe it was another reason entirely.
Either way, millions of dollars of hardware now sat fallow. This was a black eye on the company all the way up to the C-level.
tl;dr: Listen to your engineers. You hired them for their expertise.5 -
The only thing more dangerous than an alcoholic short-term-memory-challenged non-technical throw-you-under-the-bus IT director with self-esteem issues that are sporadically punctuated by delusions of superiority is one who fears for his job. Submitted for your inspection: a besotted mass of near-human brain function who not only has a 50 person IT department to run, but has also been questioned by the business owners as to what he actually does. So he has decided to show them. He has purchased a vendor product to replace a core in-house developed application used to facilitate creating the product the business sells. The purchased software only covers about 40 percent of the in-house application's functionality, so he is contracting with the vendor to perform custom development on the purchased product (at a cost likely to be just shy of six-figures) so that about 90 percent of existing functionality will be covered. He has asked one of his developers (me) to scale down the existing software to cover the functionality gaps the purchased software creates. There is no deployment plan that will allow the business to transition from the current software to the new vendor-supplied one without significantly hurting the ability of the business to function. When anyone raises this issue he dismisses it with sage musings such as, "I know it will be painful, but we'll just have to give the users really good support." Because he has no idea what any of his staff actually does, he is expecting one of his developers (again, unfortunately, me) to work with the vendor so that the Frankensoftware will perform as effectively as the current software (essentially as a project manager since there will be no in-house coding involved). Lastly, he refuses to assign someone to be responsible for the software: taking care of maintenance, configuration, and issue resolutions after it has been rolled out. When I pointedly tell him I will not be doing that (because this is purchased software and I am not a system admin or desktop engineer) he tells me, "Let me think about this." The worst part is that this is only one of four software replacement initiatives he is injecting himself into so he can prove his worth to the business owners. And by doing so he is systematically making every software development initiative akin to living in Dante's Eighth Circle. I am at the point where I want to burn my eye out with a hot poker, pour salt into the wound, and howl to the heavens in unbearable agony for a month, so when these projects come to fruition, and I am suffering the wrath of the business owners, I can look back on that moment I lost my eye and think "good times."4
-
I quit this startup side job coz I was over worked and under paid for 3 years and I decided it wasn't worth the mental fatigue and anxiety. Plus I didn't feel like it added any value to my life other than stress. Gave them at least 2 months notice (since February effective April 30th) coz as the only server side engineer+team lead, I did ALOT. Now they brought this hot shot new CTO who wants me to basically rewrite the entire app before I go while maintaining the existing system and making sure everything functions smoothly (there is a ton I chose to optimise to make things easier for the new dev who they have not hired and I have 4 weeks to go) . The app was built in mongo db now he wants it in mysql. Can't believe ask me this after breaking my neck and falling in and out if depression for this job?!! I want to laugh and scream at the same time.8
-
(long post is long)
This one is for the .net folks. After evaluating the technology top to bottom and even reimplementing several examples I commonly use for smoke testing new technology, I'm just going to call it:
Blazor is the next Silverlight.
It's just beyond the pale in terms of being architecturally flawed, and yet they're rushing it out as hard as possible to coincide with the .Net 5 rebranding silo extravaganza. We are officially entering round 3 of "sacrifice .Net on the altar of enterprise comfort." Get excited.
Since we've arrived here, I can only assume the Asp.net Ajax fiasco is far enough in the past that a new generation of devs doesn't recall its inherent catastrophic weaknesses. The architecture was this:
1. Create a component as a "WebUserControl"
2. Any time a bound DOM operation occurs from user interaction, send a payload back to the server
3. The server runs the code to process the event; it spits back more HTML
Some client-side js then dutifully updates the UI by unceremoniously stuffing the markup into an element's innerHTML property like so much sausage.
If you understand that, you've adequately understood how Blazor works. There's some optimization like signalR WebSockets for update streaming (the first and only time most blazor devs will ever use WebSockets, I even see developers claiming that they're "using SignalR, Idserver4, gRPC, etc." because the template seeds it for them. The hubris.), but that's the gist. The astute viewer will have noticed a few things here, including the disconnect between repaints, inability to blend update operations and transitions, and the potential for absolutely obliterative, connection-volatile, abusive transactional logic flying back and forth to the server. It's the bring out your dead approach to seeing how much of your IT budget is dedicated to paying for bandwidth and CPU time.
Blazor goes a step further in the server-side render scenario and sends every DOM event it binds to the server for processing. These include millisecond-scale events like scroll, which, at least according to GitHub issues, devs are quickly realizing requires debouncing, though they aren't quite sure how to accomplish that. Since this immediately becomes an issue with tickets saying things like, "scroll event crater server, Ugg need help! You said Blazorclub good. Ugg believe, Ugg wants reparations!" the team chooses a great answer to many problems for the wrong reasons:
gRPC
For those who aren't familiar, gRPC has a substantial amount of compression primarily courtesy of a rather excellent binary format developed by Google. Who needs the Quickie Mart, or indeed a sound markup delivery and view strategy when you can compress the shit out of the payload and ignore the problem. (Shhh, I hear you back there, no spoilers. What will happen when even that compression ceases to cut it, indeed). One might look at all this inductive-reasoning-as-development and ask themselves, "butwai?!" The reason is that the server-side story is just a way to buy time to flesh out the even more fundamentally broken browser-side story. To explain that, we need a little perspective.
The relationship between Microsoft and it's enterprise customers is your typical mutually abusive co-dependent relationship. Microsoft goes through phases of tacit disinterest, where it virtually ignores them. And rightly so, the enterprise customers tend to be weaksauce, mono-platform, mono-language types who come to work, collect a paycheck, and go home. They want to suckle on the teat of the vendor that enables them to get a plug and play experience for delivering their internal systems.
And that's fine. But it's also dull; it's the spouse that lets themselves go, it's the girlfriend in the distracted boyfriend meme. Those aren't the people who keep your platform relevant and competitive. For Microsoft, that crowd has always been the exploratory end of the developer community: alt.net, and more recently, the dotnet core community (StackOverflow 2020's most loved platform, for the haters). Alt.net seeded every competitive advantage the dotnet ecosystem has, and dotnet core capitalized on. Like DI? You're welcome. Are you enjoying MVC? Your gratitude is understood. Cool serializers, gRPC/protobuff, 1st class APIs, metadata-driven clients, code generation, micro ORMs, etc., etc., et al. Dear enterpriseur, you are fucking welcome.
Anyways, b2blazor. So, the front end (Blazor WebAssembly) story begins with the average enterprise FOMO. When enterprises get FOMO, they start to Karen/Kevin super hard, slinging around money, privilege, premiere support tickets, etc. until Microsoft, the distracted boyfriend, eventually turns back and says, "sorry babe, wut was that?" You know, shit like managers unironically looking at cloud reps and demanding to know if "you can handle our load!" Meanwhile, any actual engineer hides under the table facepalming and trying not to die from embarrassment.36 -
I need some advice here... This will be a long one, please bear with me.
First, some background:
I'm a senior level developer working in a company that primarily doesn't produce software like most fast paced companies. Lots of legacy code, old processes, etc. It's very slow and bureaucratic to say the least, and much of the management and lead engineering talent subscribes to the very old school way of managing projects (commit up front, fixed budget, deliver or else...), but they let us use agile to run our team, so long as we meet our commitments (!!). We are also largely populated by people who aren't really software engineers but who do software work, so being one myself I'm actually a fish out of water... Our lead engineer is one of these people who doesn't understand software engineering and is very types when it comes to managing a project.
That being said, we have this project we've been working for a while and we've been churning on it for the better part of two years - with multiple changes in mediocre contribution to development along the way (mainly due to development talent being hard to secure from other projects). The application hasn't really been given the chance to have its core architecture developed to be really robust and elegant, in favor of "just making things work" in order to satisfy fake deliverables to give the customer.
This has led us to have to settle for a rickety architecture and sloppy technical debt that we can't take the time to properly fix because it doesn't (in the mind of the lead engineer - who isn't a software engineer mind you) deliver visible value. He's constantly changing his mind on what he wants to see working and functional, he zones out during sprint planning, tries to work stories not on the sprint backlog on the side, and doesn't let our product owner do her job. He's holding us to commitments we made in January and he's not listening when the team says we don't think we can deliver on what's left by the end of the year. He thinks it's reasonable to expect us to deliver and he's brushing us off.
We have a functional product now, but it's not very useful yet and still has some usability issues. It's still missing features, which we're being put under pressure to get implemented (even half-assed) by the end of the year.
TL;DR
Should I stand up for what I know is the right way to write software and push for something more stable sometime next year or settle for a "patch job" that we *might* deliver that will most definitely be buggy and be harder to maintain going forward? I feel like I'm fighting an uphill battle in trying to write good quality code in lieu of faster results and I just can't get behind settling for crap just because.9 -
Sprint 0: This design is the appropriate amount of engineering abstraction.
Sprint 2: This is over-engineered, too much work
Sprint 5: This is under-engineered, too many edge cases
Sprint 10: This is over-engineered, component Foo could be replaced by a bash script
Sprint 42: Foo is now the cornerstone of half our business logic2 -
I am a mechanical engineer first and my companies go to sysadmin second. So software developing isnt really my main field of expertise buuttt:
WHY IS SLOOPY SOFTWARE WRITING A VIABLE EXCUSE?
Story:
Yesterday i started to migrate some stuff from our old Win 2008 Server to the new 2016. Turns out there are some MS SQL Express Servers running. Quick check for what they are turns out that they are activly used. So far so good. For other reasons we have a new MSSQL 2017 Core Licence. So i thought, hey it would be nice to just move those 2012, 2008 and 2014 Express Servers to a real one that can use the entire machines capabilities.
After some try & error with exporting one of the softwares (where i had to elevate one the user rights to sysadmin for reasons) the entire system stopped working. I didnt deleted anything or changed anything! Well, i elevated user rights. After 2 hours of support call it turns out that the software stopped working cause i gave the database user sysadmin rights. I dont know enough about MSSQL to judge wether that is logical or not, but it sounds super illogical and i suspect sloopy software writing on the manufacturers part. One way or another, the excuse from the telephone support was "yeah, our software is a very fragile child"
Okay.
After i told all that my coworkers two of them were also "yeah, that is just how the [company] software is, you have to be careful with it"
Apparently it broke in the past for other minor stuff.
As an engineer i cannot build bridges that collapse when you use the left and the right lane at the same time. For an architect it isnt okay to build an house where the front door explodes when you open a window. It is not okay for a power tool to go out in a fireball when you accidently drill plastic with it. But for some weird reasons its socially acceptable for programs to be sloopy, buggy and only working under specific conditions. Since when is it okay for a car only to work when you know specific steps to make it run? Like, throwing your spare key in the gas tank, the kick the left wheel exactly three times and finally tapping the steering wheel 5 times left, 4 times right. What? That would be ridiculous? But that is exactly how that software works. You have to follow a specific step guide to make it work, EVERY TIME.
I. JUST. DONT. GET. IT3 -
So at the beginning of the year I took a new job at a large, stable company. Leaving a failing startup, toxic leadership, and an absolutely stellar development team in the process. Given what's happened in the world since then, I'm overall pretty happy with the decision to have some more stability for me and my family.
That being said, I'm super bummed out (and weirdly burned out) now because I feel like I'm becoming a worse engineer.
I've worked for large organizations before (single digit thousands of employees), but never have I experienced a personification of enterprise memes like this. Leadership too out of touch, lots of bullshit work just to make worthless reports look good, horrific legacy codebases and infrastructure, you name it.
My biggest problem are the expectations are shockingly low. I went from a hyper demanding work environment where the fate of the entire company seemed to hang in the balance each and every week, to an environment where we literally invent arbitrary, bullshit deadlines and requirements so we have something to feel some stress about. And even still, most of the deadlines are laughably far away. The pace of work that's not only accepted, but praised is so slow that I find myself procrastinating more and more. I spend so little time doing any work, and even less time doing things that would pass as "interesting", that I feel like the engineering and problem solving part of my brain is starting to rot.
To make matters worse, the culture is weirdly confrontational despite the pace being so slow. The people here are _incredibly_ pedantic and will launch into 15 minute arguments over the tiniest incorrect details in a story title. Interrupting someone just so you can say what they were going to say is a daily trial. And most ridiculous of all, _repeating_ word for word what someone _just_ finished saying like it was your thought and you didn't even hear them. I don't even know what the motivation for this could be because it makes them look like total clowns.
I've tried to bring up some of the things I find ridiculous, but most everyone has just accepted them at this point and there's virtually no effort to try and make things better. I only get stupid non-answers like "obviously you've never worked at a large enterprise before". Yes I have. Twice. We didn't partake in half the bullshit that happens here.
Honestly this was all just a passing frustration for the first month or two, but 7 months in I'm starting to see myself become complacent. My current output would be absolutely _shameful_ to myself from a year ago, and even my personality has started to shift to the point that I just go with the flow and don't challenge anything.
I've stopped keeping up with tech trends. I've stopped experimenting with new things. I've tried to do more work on personal projects, but the burnout is starting to affect my life outside of work. In general I've just completely stopped trying, and I absolutely fucking hate it.
I also feel like a total tool for complaining about having a cushy, stable job where I barely have to do anything given the current world climate. But I'm more miserable now than I think I've every been in my career. Has anyone else experienced this and found ways to combat it? How do you get your motivation back once it's lost and there isn't even any pressure to regain it?
I totally blame myself for becoming part of this joke. That's totally on me for not continuing to push myself, but I never realized how much of my "drive" from the last job was coming from the high stakes we were operating under. I really just want to get back to being proud of my work and pushing to be better.
Anyway, sorry for the lengthy post. This turned out to be a weirder rant/self-roast than I intended. But I'm hoping this will be the first step to kicking my own ass back into shape.5 -
Aren't you, software engineer, ashamed of being employed by Apple? How can you work for a company that lives and shit on the heads of millions of fellow developers like a giant tech leech?
Assuming you can find a sounding excuse for yourself, pretending its market's fault and not your shitty greed that lets you work for a company with incredibly malicious product, sales, marketing and support policies, how can you not feel your coders-pride being melted under BILLIONS of complains for whatever shitty product you have delivered for them?
Be it a web service that runs on 1980 servers with still the same stack (cough cough itunesconnect, membercenter, bug tracker, etc etc etc etc) incompatible with vast majority of modern browsers around (google at least sticks a "beta" close to it for a few years, it could work for a few decades for you);
be it your historical incapacity to build web UI;
be it the complete lack of any resemblance of valid documentation and lets not even mention manuals (oh you say that the "status" variable is "the status of the object"? no shit sherlock, thank you and no, a wwdc video is not a manual, i don't wanna hear 3 hours of bullshit to know that stupid workaround to a stupid uikit api you designed) for any API you have developed;
be it the predatory tactics on smaller companies (yeah its capitalism baby, whatever) and bending 90 degrees with giants like Amazon;
be it the closeness (christ, even your bugtracker is closed and we had to come up with openradar to share problems that you would anyway ignore for decades);
be it a desktop ui api that is so old and unmaintained and so shitty, but so shitty, that you made that cancer of electron a de facto standard for mainstream software on macos;
be it a IDE that i am disgusted to even name, xcrap, that has literally millions of complains for the same millions of issues you dont even care to answer to or even less try to justify;
be it that you dont disclose your long term plans and then pretend us to production-test and workaround-fix your shitty non-production ready useless new OS features;
be it that a nervous breakdown on a stupid little guy on the other side of the planet that happens to have paid to you dozens of thousands of euros (in mandatory licences and hardware) to actually let you take an indecent cut out of his revenues cos there is no other choice in a monopoly regime, matter zero to you;
Assuming all of these and much more:
How can you sleep at night with all the screams of the devs you are exploiting whispering in you mind? Are all the money your earn worth?
** As someone already told you elsewhere, HAVE SOME FUCKING PRIDE, shitty people AND WRITE THE FUCKING DOCS AND FIX THE FUCKING BUGS you lazy motherfuckers, your are paid more than 99.99% of people on earth, move your fucking greasy little fingers on that fucking keyboard. **
PT2: why the fuck did you remove the ESC key from your shitty keyboards you fuckshits? is it cos autocomplete is slower than me searching the correct name of a function on stackoverflow and hence ESC key is useless? at least your hardware colleagues had the decency of admitting their error and rolling back some of the uncountable "questionable "hardware design choices (cough cough ...magic mouse... cough golden charging cables not compatible with your own devices.. cough )?12 -
# Retrospective as Backend engineer
Once upon a time, I was rejected by a startup who tries to snag me from another company that I was working with.
They are looking for Senior / Supervisor level backend engineer and my profile looks like a fit for them.
So they contacted me, arranged a technical test, system design test, and interview with their lead backend engineer who also happens to be co-founder of the startup.
## The Interview
As usual, they asked me what are my contribution to previous workplace.
I answered them with achievements that I think are the best for each company that I worked with, and how to technologically achieve them.
One of it includes designing and implementing a `CQRS+ES` system in the backend.
With complete capability of what I `brag` as `Time Machine` through replaying event.
## The Rejection
And of course I was rejected by the startup, maybe specifically by the co-founder. As I asked around on the reason of rejection from an insider.
They insisted I am a guy who overengineer thing that are not needed, by doing `CQRS+ES`, and only suitable for RND, non-production stuffs.
Nobody needs that kind of `Time Machine`.
## Ironically
After switching jobs (to another company), becoming fullstack developer, learning about react and redux.
I can reflect back on this past experience and say this:
The same company that says `CQRS+ES` is an over engineering, also uses `React+Redux`.
Never did they realize the concept behind `React+Redux` is very similar to `CQRS+ES`.
- Separation of concern
- CQRS: `Command` is separated from `Query`
- Redux: Side effect / `Action` in `Thunk` separated from the presentation
- Managing State of Application
- ES: Through sequence of `Event` produced by `Command`
- Redux: Through action data produced / dispatched by `Action`
- Replayability
- ES: Through replaying `Event` into the `Applier`
- Redux: Through replay `Action` which trigger dispatch to `Reducer`
---
The same company that says `CQRS` is an over engineering also uses `ElasticSearch+MySQL`.
Never did they realize they are separating `WRITE` database into `MySQL` as their `Single Source Of Truth`, and `READ` database into `ElasticSearch` is also inline with `CQRS` principle.
## Value as Backend Engineer
It's a sad days as Backend Engineer these days. At least in the country I live in.
Seems like being a backend engineer is often under-appreciated.
Company (or people) seems to think of backend engineer is the guy who ONLY makes `CRUD` API endpoint to database.
- I've heard from Fullstack engineer who comes from React background complains about Backend engineers have it easy by only doing CRUD without having to worry about application.
- The same guy fails when given task in Backend to make a simple round-robin ticketing system.
- I've seen company who only hires Fullstack engineer with strong Frontend experience, fails to have basic understanding of how SQL Transaction and Connection Pool works.
- I've seen company Fullstack engineer relies on ORM to do super complex query instead of writing proper SQL, and prefer to translate SQL into ORM query language.
- I've seen company Fullstack engineer with strong React background brags about Uncle Bob clean code but fail to know on how to do basic dependency injection.
- I've heard company who made webapp criticize my way of handling `session` through http secure cookie. Saying it's a bad practice and better to use local storage. Despite my argument of `secure` in the cookie and ability to control cookie via backend.18 -
I have a bit of a love/hate relationship with Brian Goetz. He's undoubtedly capable as an engineer, but he's also one of those 90's style neck beard jerks who is incapable of having a conversation with another human being and not being condescending AF.
That out of the way, this proposition and explanation is why I keep paying attention to him (well, maybe not entirely, he owns the direction of java, so yeah).
https://github.com/openjdk/...
It's reasonable, well thought out, and gives credit where it's due. While a bit non-committal, it speaks to what good has happened to java since it moved out from under the original manager (though the original owner was still far superior).
Here's hoping we see more proposals that parallel this direction.3 -
This senior engineer had this kid spend most of a day tracing down all of the instances of a certain variable so they could make heavy changes to the software. We work under a change management system of course and all of this led to two weeks of work outside of any of this. The senior engineer ended up 🔥 and the kid very close.
I'm still trying to figure out what makes someone do something like that knowing the outcome. -
Job review time,
(just a random pick from the a list).
---
"Engineering Lead"
Translation: "Chief Calculator Officer"
"Anyone can design or spec a product, get it manufactured overseas and get it to market. But will it be good? Will people buy it?"
Translation: "We're looking for a miracle"
"Take on a top notch team that is going places in Electronics, R&D and advanced product development."
Translation: "Professional Excel engineer wanted"
"This company is a little-known success story that has been operating for over X years, making mission-critical electronic equipment for use by consumers, professionals, government and industry."
Translation: "Design weapons and tamagotchis."
"Working as part of the Senior Leadership team, you will have charge of the I.P. engine and product development team spinning up new ideas and throwing them out the door."
Translation: "You're success is our success. Your failure is your failure."
"The Role
- Generate New Ideas
- Push for new products
- Drive manufacturing
- Manage a cross disciplinary team that includes Electronics, Software and Mechanical
- Project Manage new projects to completion
- Interact with marketing and sales to drive results"
Translation: "We've never hired one person to be a whole team before but we think it will work."
"On your first day, we expect:
- Strong Leadership experience and skills
- Solid Engineering Fundamentals
- Experience taking new and existing products to market
- Experience with manufacturing high-tech, mission critical equipment
- Commercial Acumen
- Bachelors in Electrical or Electronic Engineering"
Translation: "We expect you know where to hide the drugs already."
"Nice to have:
- Experience with Defense or Medical Systems
- R&D background
- MBA, B. Commerce or similar"
Translation: "By clicking on this job ad your background check is already under way."
"In return:
- A loyal and oustanding team will be there to support you
- Extremely knowledgeable experts to guide you
- Incredibly smart founders to mentor you
- The opportunity to work on a real product
- Extremely generous salary package"
Translation: "Our last dev has removed the Warrant Canary. Can you pleeease put it back?!"2 -
So I am a Software Engineer at a small scale company.
I need to coordinate with customers, understand the requirements and design and develope the solutions.
These sometimes include changing the current product a bit and customize it to fit the client needs or maybe creating a plug-in that could work with the current product and get the job done.
I love the research, design and planning part of the job, I would be super focused and will find solutions for complex stuff. Plan it all to the smallest things.
I know the solution so I can think of what code would be there what would be needede whats already there etc.
But when it comes to coding the solution my laziness kicks in.
My mind is like you already know the solution why you need to code it to.
Then I start procrastinating and end up putting myself under a pile of stuff when the deadline approaches.
FML3 -
I worked at my previous job about 8 years (hired out of school) and wasn't actively looking for a new one; I had a lot of freedom and liked my boss and colleagues, but the pay was mediocre and I was under a lot of pressure because I was the sole architect, engineer, and programmer for a good number of important applications.
Anyway, my brother-in-law told me that his employer was looking for a developer and that previous candidates fell through, and that the pay was a lot more and they're good about raises (which was like pulling teeth at my then-current job) so I applied and went for an interview.
They basically gave me an offer on the spot and wanted me to start in 2 weeks. I told them that it would be hard since I'd basically be cutting my boss's Achilles by leaving so soon and suddenly (just hiring someone would take at least a month, not counting getting applicants), but they were adamant, as the position had been vacant for a few months at that point. I got them to agree to 3 weeks and pulled the trigger, but offered to help out in my old position for a few months cause we had a big project in progress I was leading.
So the new job is great: it's a much younger office and I'm having more fun and there's a lot less pressure. Meanwhile, at the old job, the project I was leading got scrapped and the asked me to do other odds and ends until, after screwing something up I basically told them I'm done. They got a new guy quickly due to a lucky turn of events, but he couldn't pick up where I left off on a lot of projects: they're going to rewrite one because of it. My one colleague still likes to point out that I left without them having knowledge of my code (besides that I always said I'd answer questions, plus it's been 6 months now and my code is all on a TFS instance they all have access to).
I still feel a bit guilty even though I have no reason to. -
Real question, not troll. There is debate about it and I really can't figure it out.
Besides having the title software "engineer," is there really such a thing as a software engineer?
In the US, to be an engineer you have to be regularly tested by a regulated governing body, apprentice under another engineer for years, and be certified on a state level. Whereupon you are personally liable for your designs being FREE from errors.
For one thing, nobody can write bug free code, and the idea of being personally responsible for each bug is terrifying.
And two, I've seen news of people calling themselves software engineers in the USA and Canada and getting a cease and desist or sued for it, despite any level of qualification.
I'm sure there are engineers, especially electrical, computer engineers who also program.
But... ?
I don't know, I can't say either way.
That's why I'm asking.9 -
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 -
Learning how to build micro services using Spring Cloud. As I'm not familiar with this architecture, the company's lead engineer suggested me to do research & development on it, recommended me to follow official guide lines before involving me to the current under development project.
What's your advice regarding - what to keep in mind while learning micro service architecture (could be in one sentence)? It will be helpful to me. ^_^ Thank you.2
Top Tags
Weekly Rant
View