Zaemis

Some thoughts that have been living rent-free recently in my head about AI... We should be more precise when we talk about it. We’ve had "AI" for decades. Google Translate, Alexa and Siri, computer vision in video games, OCR in mail sorting, protein folding models all fall under artificial intelligence, but there’s no mass panic over these. The current progress is in generative AI, and that's where most of the public concern is. I’m guilty of the shorthand myself, saying "AI" when I mean "generative AI". People are afraid of generative AI, but the real problem is concentrated power and corporate greed. Someone wanting to sow disinformation could do so without generative AI models, and deep-pocket organizations of state could finance extreme actors if they wanted to. The tools evolved, but the risks aren’t new. The bigger problem that few are talking about is corporations who are aligning the technology for their own goals; they increasingly dicta...

Continuing my reflections on how we can better hire software engineers, I'd like to next address the topic of coding interviews. They're a cornerstone of the interview process for software engineers and take many forms, including algorithm challenges, whiteboard sessions, and take-home exercises. On the surface, the practice sounds reasonable. If we're going to pay someone to write code for us, we should verify they know how to program, right? The core problem is that coding interviews focus on superficial indicators of skill rather than the qualities that matter in real-world engineering. They're a tradition that persists not because it works, but because it feels like we're doing something rigorous. Meanwhile, engineers are increasingly refusing to participate, leaving us with a less diverse talent pool. So, if coding interviews frustrate the very people we want to hire, and they don’t generate the insights we actually need, why are we still doing them? It’s ...

I saw a recent post where a software engineer/programming influencer was encouraging: If you know how to work with C#, you can learn Java. If you know how to work with JavaScript, you can learn TypeScript. If you know how to work with GitHub Actions, you can learn Jenkins. If you know how to work with SQL, you can learn SparkSQL. If you know how to work with Angular, you can learn React. If you know how to work with Databricks, you can learn Snowflake. If you know how to work with Event Hubs, you can learn Kafka. If you know how to work with Bicep, you can learn Terraform. It's not the tools that are important, it's the concepts. Kudos for speaking the truth. With 20 years of experience in software engineering myself, I whole heartedly agree with her post. But sadly, the market doesn’t value conceptual fluency. From a job search perspective, conceptual fluency presumes you're networking and already in contact with the hiring manager, they like you, and the...

Interviews are supposed to evaluate whether a candidate can do the job. All too often, though, they become tests of endurance, performance, or obedience. And some of the most common interview questions aren’t just unhelpful, rather lazy, intrusive, and manipulative, reflecting a deeper problem in how companies approach hiring. If we want real insight, we have to ask insightful questions. That sounds obvious, but it’s staggering how many interviews still fall back on unhelpful lines of questioning. You’ve invested hours wading through half-baked applications, irrelevant referrals, and now AI slop. After all that effort, why would you waste the actual interview, the most valuable moment, with questions that produce rehearsed answers and zero useful insight? Let’s look at four of the worst interview questions to ask, not just to call them out, but to push for a smarter, more respectful way of interviewing that both values people and leads to better hiring decisions. 1. Can you explai...

Experience has shown me frameworks can be useful for maintaining structure in large code base developed by multiple teams. Every developer has different abilities and a framework enforces structure and consistency throughout the code. But I've not experienced saving any substantial amount of time on a PHP project because of a framework. The other day someone posted in the PHP subreddit asking for advice. He was about to begin work on a small project and wanted to know whether he should use a framework, and if so then which framework would be appropriate. I should have known better than to offer my two cents but I did anyway. Slim + NotORM + Twig is nice. If it's a simple project, you probably don't need much more than that. I'm not a fan of frameworks in the slightest but I do enjoy the aforementioned combination. They're lightweight and stay out of my way, allowing me to write my functionality. Another redditor picked up on my distaste for frameworks and ask...

Happy belated International Change-Your-Password Week! Earlier this month, thanks to the generous sponsorship by the great folks at Adobe , people all around the world were changing their passwords and tech blogs were parroting guidelines for choosing a strong password. But let’s be honest – passwords are a hassle. And, as Adobe was so kind to remind us, even the strongest unique password can be an open door if the company storing it isn’t doing so competently. As someone who is a programmer, I’m aware of several technical solutions to our password woes. As someone who suffers from cynical realism, I believe the barrier to adopting these solutions to be red-tape and human nature (ego and laziness). There’s no reason for every website to require their own login credentials when OpenID and OAuth exist. Perhaps we should increase liability for password storers and provide incentives to the crackers who hack them. A smart company would migrate to an SSO-provider to mitigate their responsi...

Tradukita de Please God, Give Me Something New! . Koran dankon al Jon Z kaj 黄鸡蛋/Ĉitano pro ilia kontrolado. “Jen... rigardu ĉi tiun <ligilon>. Tamen, vi devas uzi la plej freŝan version de Chrome.” Aĉ! Ĉu ni ne jam spertis tion? 15 jaroj pasis, kaj nun ni reiras rekte al la sama loko, kie ni ekiris… “Plej bone aspekta pere de .” Estas vera domaĝo. Ne miskomprenu min. Jaroj da laboro por normigi HTML, JavaScript, la DOM, CSS, ktp klarigis multajn malklaraĵojn, kaj tio ja estis necesa. Sed striktaj reguloj ankaŭ sufokas kreadon. Ĉar HTML5 kaj ĝiaj amikoj forigis kelkajn el la limigoj, la pendolo svingiĝi antaŭen. Homoj ekkreas denove. Sed, nun kontraŭas Firefox kaj Chrome anstataŭ Internet Explorer kaj Netscape. Tamen, estas sistema problemo preter la “foliumiloj militoj.” Ĉu vi memoras AOL? Facebook nun klopodas esti “La Interreto.” Ĉu vi memoras komputilegojn kaj verd-ekrajnojn? Ni puŝis ĉion al la komputila labortablo, kaj nun puŝas ĉion reen “al La Nubo.” Ĉiuj el la kvara k...

"Here... check out this (link). But you have to use the most recent version of Chrome." Sigh. Haven't we been through this already? 15 years have passed and we're headed right back to the same place we started... "Best viewed in <someone's favorite browser>." It's sad, really. Don't get me wrong. Years of standardization work on HTML, JavaScript, the DOM, CSS, etc. cleaned up a lot of messy lose ends and yes it was indeed necessary, but stringent standardization also stifles creativity. And now that HTML5 and friends have loosened some of the restrictions the pendulum has started to swing back in the opposite direction. People have started to innovate again. This time around it's Firefox vs Chrome instead of Internet Explorer vs Netscape. There's a systemic problem that goes beyond browser wars, however. Remember AOL? This time it's Facebook trying to be “The Internet.” Remember mainframes and terminals? After pushing everyt...

I didn't intend to write another blog entry so close to the conclusion of my Week with Go series, but my experiences earlier today definitely warranted a rant. Installing the SpiderMonkey JavaScript engine for use as a stand-alone interpreter on Ubuntu 10.04 LTS doesn't sound like outlandish goal. After all, CouchDB ships by default as of 9.10 and it requires a JavaScript run-time. Technologies like node.js and v8 are pretty hot right now so there might even be a few alternatives to choose from, right? WRONG! sudo apt-get install spidermonkey-bin E: Couldn't find package spidermonkey-bin There used to be such a package but apparently SpiderMonkey is "unsupported" now and was removed from the Universe repository. Sorry Ubuntu. I'm not feeling the love for Rhino. It doesn't do JIT and runs slower than a one-legged sloth. Besides, I don't feel like installing ca-certificates-java , default-jre-headless , icedtea-6-jre-cacao , java-common , libavahi-...

Proponents of Object Oriented Programming feel the paradigm yields code that is better organized, easier to understand and maintain, and reusable. They view procedural programming code as unwieldy spaghetti and embrace OO-centric design patterns as the "right way" to do things. They argue objects are easier to grasp because they model how we view the world. If the popularity of languages like Java and C# is any indication, they may be right. But after almost 20 years of OOP in the mainstream, there's still a large portion of programmers who resist it. If objects truly model the way people think of things in the real world, then why do people have a hard time understanding and working in OOP? I suspect the problem might be the focus on objects instead of actions. If I may quote from Steve Yegge's Execution in the Kingdom of Nouns : Verbs in Javaland are responsible for all the work, but as they are held in contempt by all, no Verb is ever permitted to wander about ...

People irk me when they expect PHP to behave like <insert your favorite language here>. Most recently, I ran across this blog entry Perl vs PHP: Variable Scoping via the help of PHPDeveloper.org . I'm sure Leonid is a great fellow and really smart... but he just happened to trip my irk-wire. The post is an innocent enough "here's a problem that I ran into, so I'll blog it in case someone else has the same issue." Reading between the lines though, I get the feeling his underlying belief is that because PHP and Perl are similar that they should have the same variable scoping rules, and that since PHP's doesn't correspond to Perl's that PHP is wrong and this should be documented as such. Each language is different. If PHP were so similar to Perl, it wouldn't be called PHP... it'd be called Perl. Or maybe a dialect, like PHPerl. I really wish people would stop comparing the two. Quite frankly, I don't see much similarity betwe...

There's been an interesting discussion off and on around the office this past couple of weeks about JavaScript frameworks, specifically which framework is the best so we can standardize on one. Of course I have to be difficult... my answer is none of them. As a general rule of thumb, "frameworks are evil." There are exceptions, but frameworks seem to cause a lot of unnecessary bloat, make tasks difficult to accomplish if they fall outside the intended scope of the framework, create obstacles to efficient debugging, and adversely affect page load times causing the application to appear slow and sluggish. The real question ought not be what framework is best, but rather be what exactly are you trying to accomplish with client-side scripting in the first place. Creating a rich user experience with standard JavaScript is not difficult. Many of the niceties the frameworks provide aren't magic... for example, $() is just function(x) document.getElementById(x);} . And A...