client side validation ?

If you are a freelancer don't trust the client.

NEVER!

“Get the code working first, then worry about how to clean and optimize it.”

For me when I learnt about optimization and how one thing was better than something else, I tended to focus on that. I’d have a picture of that in my mind, and would try to write as clean of code with less hacks in the middle and as optimized as I could in the first go, which slowed me the way fuck down.

After he said that to me, I realized I was stupid and just wasting time if I worried about that from the start. Would waste time, and just cause more headaches from the start than it was worth.

——

Oh also another one, I knew never to trust the client from the start but the way he said it was funny. “Never ever trust the fucking client, don’t trust them with anything. I trust Satan more than I trust the client.” 😂

Admin Access

Have you ever been in a position where you become the de-facto person who works with a certain tool, but are denied full admin access to that tool for no real reason?

Two years ago I was put on the Observability squad and quickly discovered it was my thing, implementing tracking and running queries on this third-party tool, building custom stuff to monitor our client-side successes and failures.

About a year ago I hit the point where if you asked anyone "Who is the go-to person for help/questions/queries/etc. for this tool", the answer was just me lol. It was nice to have that solid and clear role, but a year later, that's still the case, and I'm still not an admin on this platform. I've asked, in an extremely professional way armed with some pretty good reasons, but every time I'm given some lame non-answer that amounts to No.

As far as I'm aware, I'm the only dev on our team at all who uses custom/beta features on this site, but every time I want to use them I have to go find an admin and ask for an individual permission. Every time. At the end of 2020 it was happening once a month and it was so demoralizing hitting up people who never even log into this site to ask them to go out of their way to give me a new single permission.

People reach out to me frequently to request things I don't have the permissions to do, assuming I'm one of the 64 admins, but I have to DM someone else to actually do the thing.

At this point it feels very much like having to tug on the sleeve of a person taller than me to get what I need, and I'm out of ways to convince myself this isn't demoralizing. I know this is a pretty common thing in large companies, meaningless permissions protocols, and maybe it's because I came from IT originally that it's especially irritating. In IT you have admin access to everything and somehow nobody gets hurt lol-- It still blows my mind that software devs who make significantly more money and are considered "higher up" the chain (which i think is dumb btw) are given less trust when it comes to permissions.

Has anyone figured out a trick that works to convince someone to grant you access when you're getting stonewalled? Or maybe a story of this happening to you to distract me from my frustration?

I just found out at my company it is policy to perform random drug and alcohol testing of all employees. I guess this makes some sense for other parts of the business where people use heavy machinery, etc. but they also test office workers.

I don't take drugs and I never drink during the day but I don't want to be tested. I am a professional person and I am trusted with development of our software and valuable internal and client databases so why cant they trust me with this? There are many developers who produce poor quality work even without any drugs, etc. Surely the quality of my work is enough.

Apparently here in Australia if I am asked to take a piss test and refuse they have the right to sack me. If they ask me I think I might resign.

Want to make someone's life a misery? Here's how.

Don't base your tech stack on any prior knowledge or what's relevant to the problem.

Instead design it around all the latest trends and badges you want to put on your resume because they're frequent key words on job postings.

Once your data goes in, you'll never get it out again. At best you'll be teased with little crumbs of data but never the whole.

I know, here's a genius idea, instead of putting data into a normal data base then using a cache, lets put it all into the cache and by the way it's a volatile cache.

Here's an idea. For something as simple as a single log lets make it use a queue that goes into a queue that goes into another queue that goes into another queue all of which are black boxes. No rhyme of reason, queues are all the rage.

Have you tried: Lets use a new fangled tangle, trust me it's safe, INSERT BIG NAME HERE uses it.

Finally it all gets flushed down into this subterranean cunt of a sewerage system and good luck getting it all out again. It's like hell except it's all shitty instead of all fiery.

All I want is to export one table, a simple log table with a few GB to CSV or heck whatever generic format it supports, that's it.

So I run the export table to file command and off it goes only less than a minute later for timeout commands to start piling up until it aborts. WTF. So then I set the most obvious timeout setting in the client, no change, then another timeout setting on the client, no change, then i try to put it in the client configuration file, no change, then I set the timeout on the export query, no change, then finally I bump the timeouts in the server config, no change, then I find someone has downloaded it from both tucows and apt, but they're using the tucows version so its real config is in /dev/database.xml (don't even ask). I increase that from seconds to a minute, it's still timing out after a minute.

In the end I have to make my own and this involves working out how to parse non-standard binary formatted data structures. It's the umpteenth time I have had to do this.

These aren't some no name solutions and it really terrifies me. All this is doing is taking some access logs, store them in one place then index by timestamp. These things are all meant to be blazing fast but grep is often faster. How the hell is such a trivial thing turned into a series of one nightmare after another? Things that should take a few minutes take days of screwing around. I don't have access logs any more because I can't access them anymore.

The terror of this isn't that it's so awful, it's that all the little kiddies doing all this jazz for the first time and using all these shit wipe buzzword driven approaches have no fucking clue it's not meant to be this difficult. I'm replacing entire tens of thousands to million line enterprise systems with a few hundred lines of code that's faster, more reliable and better in virtually every measurable way time and time again.

This is constant. It's not one offender, it's not one project, it's not one company, it's not one developer, it's the industry standard. It's all over open source software and all over dev shops. Everything is exponentially becoming more bloated and difficult than it needs to be. I'm seeing people pull up a hundred cloud instances for things that'll be happy at home with a few minutes to a week's optimisation efforts. Queries that are N*N and only take a few minutes to turn to LOG(N) but instead people renting out a fucking off huge ass SQL cluster instead that not only costs gobs of money but takes a ton of time maintaining and configuring which isn't going to be done right either.

I think most people are bullshitting when they say they have impostor syndrome but when the trend in technology is to make every fucking little trivial thing a thousand times more complex than it has to be I can see how they'd feel that way. There's so bloody much you need to do that you don't need to do these days that you either can't get anything done right or the smallest thing takes an age.

I have no idea why some people put up with some of these appliances. If you bought a dish washer that made washing dishes even harder than it was before you'd return it to the store.

Every time I see the terms enterprise, fast, big data, scalable, cloud or anything of the like I bang my head on the table. One of these days I'm going to lose my fucking tits.

This day I have received the most glorious news in e-pistolary form. For some years, I was suffering in support of a client who was, well, insufferable. My presence there paralleled the divine comedy in both essence and fact.

I opened the missive, expecting another plea to bail them out of whatever clusterfuck they found themselves in. Instead, what I found was something truly magical.

"Hey Human,

I hope this finds you well. I'm not sure if you remember a few years back, we were trying to decide between IBM Cloud and AWS. Well, after years of battling FF*, we're finally moving ahead with AWS. He failed one too many times to deliver anything visibly. After you left, there was no one left he could use to steal credit, ideas, and work.

FF is still pushing to have them use IBM cloud as a "warm backup" in the event "AWS fails." We will see where that goes.

I figured you'd like to know; you were the void in the wilderness for a long time. I don't want to think about how much time we could have saved if we had just listened.

PeeEm**"

This event represents a personal victory, albeit belated, over a few peoples' absurd amount of privilege. Towards the end, I was vicious about my contestation to the insanity of adopting a desperate hedge attempt-as-cloud offering from a failing company. Some examples:

// cloud 'strategy meeting'
Moi: What cloud platform are we looking at using?
FF: We're looking at IBM cloud and AWS as a second.
Moi: Why is that? I understand you're obligated to rep your offering first, but that decision doesn't seem to have the customer's best interest at heart.
FF: IBM cloud is a market leader; AWS isn't as good.
Moi: I see. I mean, that's the tech equivalent of the company's fleet management considering monkeys on tricycles as a strong competitor to service trucks, but I get what you mean.

// steering meeting
Director: Who can we look to as an example? Who is currently using the IBM cloud?
Moi: No one; they account for a single-digit portion of the actual cloud market. Their long game to sell you a "Hybrid Cloud," which means put some front end payload in a CDN, and buy n-frame units of IBM z servers for the DC with IBM gateway appliances acting as connective tissue. So it's not the cloud at all, really.
Director: How does it compare in cost?
Moi: It's generally 40% more expensive than other clouds, and it only goes higher as you option their software.
Director: What about Watson? I hear Watson is good?
Moi: It's a brand name. Most of the "Watson" product is just a facade on top of FOSS products like Spark, Hadoop, Elasticsearch, etc.
Director: Those were words. They sounded good. FF say it's good tho so we'll believe him because we're from the same city.
Moi: *deletes Director from LinkedIn*

Moral of the story: Never trust a vendor that only recommends their products.

*FF = FatFuck - an embarrassingly rotund individual whose girth is roughly equivalent to his height. He shit his way into an IBM architect position in his mid-20s purely due to winning the visa lottery. He had fake hair glued to his head for his wedding to hide his male pattern baldness; his arrange-married wife undoubtedly cries herself to sleep after sex.

**PeeEm - the then project manager, now portfolio manager of some satellite projects. An overall decent human being, capable.

This was not exactly the worst work culture because the employees, it was because the upper level of the organization chart on the IT department.

I'm not quite sure how to translate the exact positions of that chart, but lets say that there is a General Manager, a couple of Area Managers (Infrastructure, Development), some Area Supervisors (2 or 3, by each area), and the grunts (that were us). Anyway, anything on the "Manager" was the source of all the toxicity on the department.

First and foremost, there was a lack of training for almost any employee. We were expected to know everything since day-1. Yes, the new employees had a (very) brief explanation about the technologies/languages were used, but they were expected to perform as a senior employee almost since the moment they cross the door. And forget about having some KT (Knowledge Transfer) sessions, they were none existent and if they existed, were only to solve a very immediate issue (now imagine what happened when someone quit*).

The general culture that they have to always say "yes" to the client/customer to almost anything without consulting to the development teams if that what was being asked to do was doable, or even feasible. And forget about doing a proper documentation about that change/development, as "that was needed yesterday and it needs to be done to be implemented tomorrow" (you know what I mean). This contributes to the previous point, as we didn't have enough time to train someone new because we had this absurd deadlines.

And because they cannot/wanted to say "NO", there were days when they came with an amount of new requirements that needed to be done and it didn't matter that we had other things to do. And the worst was that, until a couple of years (more or less), there was almost impossible to gather the correct requirements from the client/user, as they (managers) "had already" that requirement, and as they "know better" what the user wants, it was their vision what was being described on the requirements, not the users'...

And all that caused that, in a common basis, didn't have enough time to do all this stuff (mainly because the User Support) causing that we needed to do overtime, which almost always went unpaid (because a very ambiguous clause of the contract, and that we were "non-union workers"**). And this is my favorite point of this list, because, almost any overtime went unpaid, so basically we were expected to be working for free after the end of the work day (lets say, after the 17:00). Leaving "early" was almost a sin for the managers, as they always expected that we give more time to work that the indicated on the contract, and if not, they could raise a report to HR because the ambiguous clause allowed them to do it (among other childish things that they do).

Finally, the jewel of the crown, is that they never, but never acknowledge that they made a mistake. Never. That was impossible! If something failed on the things/systems/applications that they had assigned*** it was always our fault.

- "A report for the Finance Department is giving wrong information? It's the DBA's fault**** because although he manages that report, he couldn't imagine that I have an undocumented service (that runs before the creation the report) crashed because I modified a hidden and undocumented temporal table and forgot to update that service."

But, well, at least that's on the past. And although those aren't all the things that made that workplace so toxic, for me those were the most prominent ones.

-

* Well, here we I live it's very common to don't say anything about leaving the company until the very last day. Yes, I know that there are people that leave their "2-days notice", but it's not common (IMHO, of course). And yes, there are some of us that give a 1 or 2-weeks notice, but still it's not a common practice.

** I don't know how to translate this... We have a concept called "trusted employee", which is mainly used to describe any administrative employee, and that commonly is expected to give the 110% of what the contract says (unpaid overtimes, extra stuff to do, etc) and sadly it's an accepted condition (for whatever reasons). I chose "non-union workers" because in comparison with an union worker, we have less protections (besides the legal ways) regarding what I've described before. Curiously, there are also "operative workers", that doesn't belong to an union, but they have (sometimes) better protections that the administrative ones.

*** Yes, they were in charge of several systems, because they didn't trust us to handle/maintain them. And I'm sure that they still don't trust in their developers.

**** One of the managers, and the DBA are the only ones that handle some stuff (specially the one that involves "money"). The thing that allows to use the DBA as scapegoat is that such manager have more privileges and permissions than the DBA, as he was the previous DBA

Working as a part time student on an app and until now I thought I was the king of software development.
Well, fuck me and my high horse.

Today the stuff we send from the client to the server didn't arrive, so I asked the backend guy if he could take a look at the packages arriving. He did and told me the data was messed up.
I did only design stuff the last week or so, so I was very confused. After reverting back to one old commit after the other it struck me.
I still don't know how such a dumb mistake could have happened to me, the king of Android apps, but apparently I replaced all occurrences of a specific keyword in just the strings and comments of the whole project. Key became KeyList, so instead of <Keys> my XML contained <KeyList> which made no goddamn sense whatsoever.
Did I mention that we have an important deadline tomorrow? Yeah...

So now I leaned my lesson. Never trust XML.

JK I'm dumb. That's the lesson here.

Important memos to future self:

If the specs the client gave you seem written by a confused pre-teen, run.
If the client says something like "this can't possibly take THAT long", run.
If the client can't pay you enough, but reassures that (in return) he won't stress you and let you work in peace without imposing deadlines: he's lying, run.
If he politely asks to do something but then when you say no he keeps insisting, Don't. Give. In. Ever.
If the project seems shitty and not likely to have success, but hey, seems also simple and easy: it's not. But it's shitty anyways.

And on top of all: trust your fucking guts, you've been right tons of times by now. You didn't want to do this but you forced yourself, because "it's still an opportunity" and stupid slogans like that. Never again.

When in an application security talk put on by our cyber security department and one team (not mine) is being chastised for only doing client side validation, another dev asks so at what point can we trust the user? A few people nod and indicate they want an answer, and the speaker, said never, you never trust the user.

I can't believe people can graduate and get a job and keep a development job, especially in a highly government regulated company like where I work

My job in company to developed e-commerce website as a full stack developer.

History of that project.

Company paid 300,000 INR to the local web development firm for developing previous website and they developed website without bootstrap/SSL/Even save information of high profile client in plain text.

I am not angry on that web firm ,I am laughing on my company because such client never trust on independent developers who work hard ,code day and night to complete freelancing projects.

I hope my work will make differnce in their selling.

"Never trust the client"

Said about game clients, but applies in other situations too!

36 or sth..
Trying to fix production for xy client without them noticing someone fucked up everything with the previous deploy.. (wasn't me)..
Anyhow, managed to deploy my changes plus fix for the previous fuckup.. in the morning it all worked as it should.
Why it took me so long? Because why bother writing down what changeset was used for deploy.. It's much more fun to guess.. Multiple times.. Anyhow, I managed to figure approximate code for that deploy & merge my changes & fix everything.. + later found out looooads of uncommited changes on the guys computer.. :/ So yeah, never trust a bunneh!!

The customer may always be right, but you are not a customer, you are a client. As a client you have come to us because you have no idea what you are talking about. Rarely do you even know what it is you even want. So how can you be right about something you know nothing about. I want you to be happy with the end product; I emotionally need it as it determines how I value myself as a developer. So trust me when I tell you that you are wrong. That is why you are my client. To give you what you never knew you wanted.

Let me run something by all of you. Let's say you once started freelancing as a "Plan B" in case your full-time gig dropped you. Over 12 years you've managed to build a long-standing personal brand around that occasional freelancing. You have several clients who adore you and the work you do and they tell you they would be lost without your talent and have nowhere else to go and nobody else they trust. You know, because in the past you tried to send them elsewhere (for various reasons) and they just kept coming back.

You get laid off from the full-time gig and ACME Company calls and interviews you as a top candidate they're really interested in for that same type of work for a full-time job they're offering.

Here's the catch...if hired, you have two months to basically erase your personal brand and agree never to do any freelancing work as before, even on your own time on evenings and weekends. ACME wants your full focus and attention. Additionally, you find out that the person you'd be replacing is being let go because they weren't sufficiently tech-skilled for the job. And, with a little digging, you find out that person _also_ had several freelancing gigs going on the side. Probably for the same "Plan B" reason. Which is probably why ACME is demanding exclusivity.

Your client base is small. ACME says "we don't care". The work you do is 90% automated and easily achievable in just minutes a day on a weekend or evening. ACME says "doesn't matter". You already had full-time work to begin with so you weren't doing a ton on the side. ACME couldn't be less interested in this "excuse". And you're not keen on the idea of burning down your brand, especially with no guarantees of any kind in the present IT industry hiring/firing/layoffs climate. ACME says this issue is make or break for them.

If you get to the offer stage do you:
a) Flip the bird to your brand and clients you've built up for over a decade and memory-hole it?
b) Negotiate a non-compete clause with ACME, agreeing not to take on any new clients while working full time for them?
c) Flip the bird to ACME and look for something else?

Asking for a friend. ;)

And that, folks, is why you never do a rush job, no matter how urgent, without an RFP and answering estimate followed by a signed statement of work confirming agreement to the estimate. Even with a prearranged, perpetual contracting agreement. And also why you NEVER deliver the end product without payment. No matter how much you trust your client or believe they will do right by you, process still matters.