Showing posts with label PayPal. Show all posts
Showing posts with label PayPal. Show all posts

Sunday, 10 March 2024

Ten Professional Hazards Of Writing Code For A Living

Human beings are creatures of habit. Any profession which entails long sustained periods of doing things or thinking a certain way, will have an influence on its practitioners. Years of being a programmer have changed me. In all fairness, some of these traits already existed way before I wrote my first Hello World program, though they were certainly magnified after that.

Here are some of the ways my job as a software developer have shaped me as a person. Some of these may make me look like an utter moron. I assure you that I am of at least average intelligence. It's just the job.

1. Counting from zero

Probably the most stereotypical quirk ever. "Programmers tend to count from zero". Yeah, right. The stereotype exists because in almost all programming languages, counting does begin from zero.

Do I count from zero? No, that's silly. I don't, for instance, look at a cluster of five apples and tell you there are four. Any programmers who do, I suspect, are just trying too hard for geek cred.

There are five apples, not four.

However, it does happen if I'm looking at rows of data. If I see an MS Excel worksheet with data all the way to number 100, I am going to think there are 101 rows of data. It could be because spreadsheets are usually the way I visualize arrays in my head (especially two-dimensional arrays) so my brain subconsciously thinks of spreadsheets as arrays.

Thus, while this stereotype is way overblown, there's some truth to it.

2. Being easily startled

When deep in the throes of writing code, programmers tend to concentrate really hard. I am no exception. There have been plenty of times when my brain is on a one-track highway through some programming logic when someone interrupts me by speaking in my ear or tapping me on the shoulder.

Violently startled.

And sometimes, my reaction can be... absurdly violent. Spilled coffee, sudden jumps, things like that.

This doesn't happen all that much these days. For one, I work from home. Very few people get to interrupt me. And even if they do, the fact is, I simply don't concentrate as hard as I used to.

3. Being very literal

One of the hallmarks of writing code is being drawn into the true or false dichotomy. Thus, there's this tendency to interpret everything as a "yes" or "no" question. To be fair, sometimes the question is literally phrased this way. But that's only as a manner of speaking; often, the asker means to ask a bigger question.

No capacity for nuance.

And because of this tendency, I tend to miss it.

I remember being at an interview where the hiring manager asked me if I knew how the PayPal IPN works. To me, the answer was obvious. Yes, I do. It was only after an awkward pause, and the interviewer rephrased his question, that I understood that he actually expected me to demonstrate how it works.

There were other interviews where I was asked similar questions where I simply said "Yes" or "No". But honestly, I also feel that if you're going to ask a programmer questions like that, you should also be prepared for replies like that.

4. Single-mindedness

This next one does not apply to all techs or even all programmers. But there's a fair number of programmers who tend to take a very insular view when writing code. This can be useful when you're writing a single-use method; as small as possible. Not so much if you're trying to design an entire system.

Laser focus... or just
tunnel vision.

And in real life, that can have negative consequences too. I've gotten into trouble with the wife for doing the correct thing... at the wrong time, or under the wrong conditions. Because the correct thing, in isolation, is the correct thing. But few things in life exist in isolation.

You don't want to wash the windows when it's raining. Or flush the toilet before taking a piss. All this is putting the cart before the horse, which can happen when you consider only the task at hand and fail to take the larger context into account.

5. Overusing techspeak

Tech work comes with a whole lot of terminology, some of which we're sometimes guilty of assuming that non-techies understand. After all, techspeak has become increasingly mainstream over the last decade as technology has become more entrenched with the general public.

This does not automatically mean that everyone knows what SSL is (despite a staggering majority of websites employing it). Or that a gateway doesn't always mean that entrance to a building enclosure. Or that when we refer to something as a "string literal", we actually just (kind of) mean "text".

No, not that kind of string.

And yes, I'm just as guilty as other tech geeks.

We're not trying to sound smart when we break out the tech jargon, cross my heart. Mostly because we are smart, and know it. No, it's largely because our work practically demands that we speak in what could almost be a different language.

6. Expecting output

As mentioned before, I tend to interpret things very literally. However, this also applies in reverse.

As a consequence of writing functions which expect very specific data type values in a very specific order, as input, and produce output which is also of a very specific data type, what happens is that this has a tendency to manifest when I ask questions of other people: I tend to expect a certain output and only that output. And when I ask for A, and people give me B, C and D in addition to A, I tend to get annoyed.

A lot of irrelevant information.

It's human nature; people want to be helpful. But what usually ends up happening is that they give you a lot of information that has nothing to do with what you wanted in the first place.

7. Cynical

Expecting the worst, or not believing it when things go well, is something ingrained in developers who do a lot of testing, which, let's face it, is pretty much all devs at this point.

Does your code ever run perfectly the first time? And when it did, were you happy or wary?

Glass is always half-empty.

Unless it's something really simple that would have been expected to go right, sometimes when things go too smoothly, I get worried.

My time running code has taught me that when no warnings or errors are reported, it's rarely because I did everything right, especially if it's the first run. No, there are probably bugs and gotchas, and they're well-hidden!

8. The How 

One more quirk of being a web developer is that one of the first questions we tend to ask is the How question. It's a professional hazard that may be shared by engineers in general.

Even when I'm asking something like "why did I get an error 500 on this API endpoint call?" it usually gets formattered as "how the hell did I get an error 500 on this API endpoint call?"

Examining how things work.

That's relevant, I promise. Because even in my early days as a web developer, I was curious about how things worked. I would find stuff on the web, wonder how it was done, and then I would make my own, just to prove I could. This also applies to other things in my life, non-tech related. I'd look at something, figure out the how, and make my own. I'm not sure if I'm this way because I was a web dev, or I became a web dev because I'm this way.

9. Lack of sympathy

I've been accused of having a less than exemplary bedside manner when people complain about their shitty careers or lack of opportunities in the job market. I've also been less than impressed with people who claim to envy the fact that I work in tech.

Heart of stone.

Really? Do people want to potentially spend days sifting through code, making changes that may end up creating problems bigger than the one they're trying to solve? Would they enjoy having to constantly remind their less tech-savvy colleagues that software development is not witchcraft and still has to conform to logic? Do they want to go through the slog I did, in order to get where I am now?

I know I don't. I simply happen to enjoy writing code enough to not overly mind that rest of the bullshit I have to put up with. People want the perceived better pay and job security of tech, but the job itself would drive them nuts.

And I have no sympathy precisely because I know I'm not better than the average schmuck. In the sense that, the moment I'm of no use, I'll be put out to pasture like anyone else. Look at the mass layoffs happening in Big Tech if you're not convinced. Job security? What a joke, right?

10. Flowcharting

Agile practices include making use of a Kanban Board system. The use of said system is good for training an organized mind, and lends into the software development practice of breaking up a huge problem into smaller, more manageable tasks.

The good old
divide-and-conquer.

And this has translated over to my daily life, to things like chores and personal projects. Even long-term goals like language learning. Everything is obsessively broken up into smaller sub-components, then managed.

The wife thinks I'm certifiably insane. She doesn't understand why mopping the kitchen floor and mopping the living room floor are two separate tasks, and have to be scheduled. Honey, I'm just a software dev. It's who I am.

What a hazardous list!

Are you a programmer by trade, and if so, how many of these apply to you?

How many apples do you see?
T___T

Saturday, 5 November 2016

Denial of Service Attack on Dyn!

Boy, that does sounds like the title of a sci-fi flick.

Anyway.

I'm sure many of you have heard about the massive DDoS attack on Dyn by now. You know, the one that caused several Internet services to be unavailable for extended periods of time? Services like PayPal, Amazon and Twitter? It happened just around the third week of last month and caused quite a stir.

Dyn themselves released a statement on this attack. The details are interesting. Apparently, while Dyn employs safety and security features such as load-balancing and malware protection, the attack that occurred was of an unprecedented scale and sophistication, and actually caused them some concern. Dyn is a Domain Name Server (DNS), which basically means they help map URLs to numbered IP addresses, the kind only computers can read without great discomfort. And the attack caused those addresses to go AWOL for the duration.

OK, so what's a DDoS?

For those who aren't sure what a DDoS is, it stands for Distributed Denial of Service. What happens is that attackers make use of several computer terminals to send requests over the Internet to their target, flooding it with traffic and eventually causing it to stumble (or even crash) under the load. Mothers would probably understand this one - imagine feeding a  baby, talking to the mother-in-law on the phone while five other kids clamor for your attention. Now imagine juggling five babies, ten phone conversations and twenty kids. And then multiply that stress level by several millions.

That's what Dyn's servers had to deal with - a motherload (pun intended) of spam in one go, drowning out the legitimate users of their services.

Now, while the attacks were of an extensive scale, the nature of the attack was DDoS, which has existed for as long as - well, let's just say that DDoS ain't the new kid on the block. If I were to say it has been around for 30 years, that wouldn't be stretching the truth.

Yep, older than this.

The mode of attack wasn't new - it was the implementation that gives one pause.

The Internet of Things

Unlike the old days, in this particular assault, venues of attacks weren't restricted to computer terminals with an Internet connection. Now many things have Internet connections - mobile phones, copiers, webcams, smart toasters, the list of devices goes on. Now with the Internet of Things being in vogue, Dyn was under siege from all manner of devices. And that's a scary thought. Imagine Twitter being brought down by your refrigerator.

A group that calls themselves New World Hackers has claimed responsibility behind the attack, and stated that it was their intent to bring awareness to the vulnerability. Whatever their intentions really were, I say bravo - it certainly accomplished that. A great many people have been shaken out of their complacency.

I think many people constantly underestimate just how dangerous the Internet is. It's a useful tool, yes, and at times an untamed and unpredictable one. Who's to say the device you're reading this blogpost on, isn't at this moment being compromised for nefarious purposes? You think that nifty new antivirus program you bought last year, or even last week, is bulletproof? Please. As long as you're connected to the Internet, you're vulnerable. Don't ever forget that. The worst thing is, dependency on the Internet is growing as we speak. Can't log into your computer without a Microsoft account? Gotcha. When's the last time you used your phone for, I dunno, making a call instead of surfing the net?

If you've gone this far without any obvious signs of having been compromised, it's not because you're good, it's not because you're well protected, it's not because God is smiling on you after you gave up your seat to the old lady on the train today, and it's certainly not because hackers are afraid of you. It's because you've been lucky. Simple as that.

Ya feelin' lucky, punk?

There anything you can do about it? Sure. Don't use the Internet. But please don't heed my advice, because that would eventually put me out of a job.

Seriously, though.

The Internet is a useful tool (did I just say that twice in one blogpost?) but don't ever let it be more than that. Exercise due caution. Don't get over-dependent on it, because I'm pretty sure this historic attack isn't a one-off thing. I mean, really, do you absolutely need a smart toaster? The capability is in place, and the potential to do a great deal of harm on a massive scale is there, and has been there a while now. This attack shouldn't have surprised anyone. It was a matter of when, not if.

At your (denied) service,
T___T