Latest Posts (20 found)
iDiallo 4 days ago

How Many Tokens Did You Burn Today

Early in my career, a manager at one of the big firms where I worked made a request so absurd it remains etched in my memory. I walked back to the team, repeated what he had asked, and couldn't finish the story without laughing. He wanted me to create a pie chart, of lines of code, per developer, per week. We all lost it. Our lead developer asked if, by any chance, the manager's eyes looked glassy. We laughed even harder. Because yes. Yes, they did. He was always high. That was twenty years ago. I've repeated that story countless times, and it always drew chuckles as we discussed the disconnect between software teams and management. Any software engineer could relate. We all knew that lines of code were a meaningless metric. A junior could write a thousand lines of spaghetti. A senior could fix the same problem with forty elegant ones. But then, last week, I found my name at the top of a leaderboard. My employer had been exploring productivity tools and trialed one they thought would be useful. After the trial, they were quoted $500k a year. The tool tracked developer productivity and integrated with Atlassian products, Microsoft, and many other services we used. The price was too steep, so it was dropped. A couple of months later, the same company came back with a discount. The exact same tool for just $50k a year. My employer jumped at the opportunity. How many bytes did you use today? I'm looking at this dashboard right now and I see my name at the top of the leaderboard. I click on the widget, and a pie chart appears. There it is: a breakdown of the total lines of code my team has produced using AI, by individual. This isn't limited to my employer. Every company is putting something together to track AI usage and justify the investment. Instead of tracking project completions, we're tracking how many lines of code each developer generated with AI. And the joke's on me, because nobody is laughing. The whole industry is applauding and encouraging employees to use more of it. I didn't become the champion because I have some neat agentic workflow. It was done by complete accident. While using an LLM, I accidentally selected "planning mode" for a request that had already been planned. The agent ran for several minutes, burning tokens to resolve a problem that didn't exist. Just like that, I made it to the top, without ever writing a single line of code. If this widget is taken at face value, it won't be long before developers start gaming it deliberately. Just let the agent run overnight, and your employer can claim a 10x improvement in productivity. We didn't use line count as a productivity metric in the past because it never made sense. Whenever we refactor code, we often end up with less than we started with. In fact, much of the time I spend modifying AI-generated code is spent deleting unnecessary things it created. Should we track negative lines of code? The better you are at programming, the worse your numbers look. We are assessing developers by the lines of code. I've watched AI evangelists ask "how many tokens did you burn today?" They were trying to convince an audience that productivity is directly proportional to token usage. It reminds me of the transition from paper to computers. A computer evangelist of that era might have asked: "how many bytes did you use today?" Token counts, lines of code, bytes, none of these have anything to do with actual productivity. Metrics are often entirely disconnected from what they're meant to measure. I've seen companies rely on story points only to watch employees point every ticket as high as possible. Choose lines of code as your metric, and lines of code will increase. Reward the highest contributor, and watch everyone double or triple their output by the next performance review. It's a silly metric but it serves a purpose, just not yours. AI companies promote token usage and associate it with productivity because they directly benefit from it. Imagine an internet service provider that charges by the byte. What would their recommendation for productivity be? "Use more bytes!" The best engineers I've ever known wrote less code, not more. They deleted things. They simplified. They understood that the goal was never the code itself. They solved problems, they made the system reliable, and they served the user. Measuring developers by output volume, whether that's lines, commits, or tokens, mistakes the exhaust for the engine. Every era of tooling brings a new class of metric that mistakes activity for value. The spreadsheet didn't make accountants more productive just because they could fill more cells. AI won't make developers more productive just because it can generate more code. We aren't even tracking if the right problems are being solved, and solved well. If the productivity dashboard can't answer that, it's not measuring productivity. It's measuring the subscription.

ai AI programming Programming
0 views
iDiallo 5 days ago

Amber Alert with Spam URL?

Well that was weird. I just received an Amber Alert and the link led to a spammy looking website. The link leads to a 3gp file converter which is highly unusual. But the more I look at it, I have the impression it's a mistake. Most likely, they have exceeded the maximum number of characters for the Emergency Service alert. Here is the message: AN AMBER ALERT HAS BEEN ACTIVATED BY THE CALIFORNIA HIGHWAY PATROL. DALEZA FREGOSO WAS LAST SEEN ON MAY 24, 2026 AT 0400 HOURS IN LOS ANGELES COUNTY. THE SUSPECT VEHICLE IS A WHITE 2019 WHITE LAND ROVER DISCOVERY CA 9DAW715. CLICK ON THE LINK FOR ADDITIONAL INFORMATION. https://bit.ly/A0 It seems like the total character count is 288. I'm not sure if the title should be included but if I add and the double space after, then we have 320 characters. Is this the character limit for emergency services? When I clicked on it, it took me to the bitly preview page: And clicking on the button, I'm taken here: Suspicious Link I was starting to wonder if this was even a real Amber alert, and if somehow this was a spam message that was sent through. But unfortunately, it is a real amber alert, as I was able to find the matching alert on missingkids.com . However, I don't see a way to request a correction. I understand that bitly was often used to shorten links, but there should be a way for a service like amber alert to test those links before they are sent. At least on my android, once I click on the link, the alert is dismissed never to be seen again. When the link is incorrect, now we have this problem where we can never get the information back. In this case, I was only able to get the link because I received the alert on both my phones. Also I've learned that Amber alerts have a character limit of 360 characters . So I'm still not sure what went wrong with this one. Update: 39 minutes later (8:25pm) a second message was sent with a correction. Corrected Link Most likely a copy and paste error.

mobile Mobile security Security
0 views
iDiallo 1 weeks ago

The commencement speech that shook the world

There he was, the man at the helm of innovation. Eric Schmidt, the former CEO of Google. The man who once said, google doesn't need to record your conversation, it already knows everything about you. Yet he didn't see this one coming. In his speech, he looked clear-eyed into the crowd of graduates and told them that AI is inevitable. There was a group of people who will have a hard time joining the workforce. Companies keep using AI as the excuse for laying off workers. Dario keeps telling us by next year, AI will take over all jobs and there is nothing we can do. They will have nothing, and they better embrace it and be happy. Well, they will have a school loan, but that’s it. If you were an external observer, maybe an alien watching humanity from a distance, you would think that AI is a new species that emerged from a lake and is taking over the world. You would never tell that the people spreading this fear are also the ones selling the tool that they swear will turn us all into gods. It's not just a capable tool that can be useful for coding, writing, and retrieving existing information. No. It's the word itself. The all or nothing. The alpha and the omega. And it comes as a monthly subscription from a handful of companies. What Mr Schmidt was saying to these graduates is that we are done innovating. Now we regurgitate. And then he was booed. He tried to keep talking but the boos were overwhelming. Somewhere between his words, he managed to say that being anti AI is akin to being anti immigrant, trying to score points. I don’t think it worked. When I read the news, I first read through the transcript of his speech. It seemed as if he was able to go through his material. But I was wrong. Watching his performance on video was a whole other story. There was a man, who had practiced his speech in front of a mirror, most likely with Gemini listening and providing feedback. It probably told him that his speech was brilliant. That it was grounded, and encouraging. "The kids will love it." What he failed to see is that booing was not in the training data. No way Gemini was going to tell him that, because it is programmed to be agreeable and friendly. So yes, he was booed every time he mentioned AI. But I think there is a lesson in innovation right there. AI learns from existing material. It can hardly deviate from what it already knows. When you ask it to come up with something new, it will show you something that seems new, because obviously you don't know all the material it was trained on. If it doesn't have the information, it can't tell you that it doesn't know. It will make it up instead. But what these graduates did was exactly what differentiates people from the robots. They did something completely unexpected. They booed Eric Schmidt. They innovated. Something tells me that kids will be just fine. I may never be able to convince my mom to stop sharing AI videos , but my kids will learn to navigate it. They will continue to innovate. Maybe AI will be like a calculator for them. They will know how and when to use it for maximum benefit and prevent the psychosis altogether. It's never gonna be a replacement for thinking. I was really happy to see the booing because it was the last thing they expected. Just a few days ago, the president of Glendale Community College was booed as well because she chose to have an AI read the graduates names and it butchered the process. AI is not inevitable. It's a nice addition. That’s it. We don't just have to accept things as they come to us. The most valuable human quality in an age of automation is exactly what AI cannot provide: the ability to defy expectations, introduce chaos, and create truly original outcomes. That is precisely the power of human innovation. For fun, I copied the commencement speech from a video and passed it through gemini, it complained about the grammar, but as I said earlier, it couldn't predict the outcome: The emotional arc is clear: acknowledge fear → restore agency → define values → point toward possibility. It reads like something that wants to meet graduates where they actually are, rather than giving them generic optimism. Then I asked it if it would result in booing: What makes the speech work is that it does not say: Instead, it says: That framing is resilient. Not so resilient after all. Anyway, congrats to the 2026 graduates! “everything will be fine,” “stop worrying,” or “technology is inherently good.” the future is undecided, humans remain morally responsible, and participation matters.

ai AI career Career business Business
0 views
iDiallo 1 weeks ago

How to Talk to Your Coworkers

You know you explained the same issue before in two or three different places, yet here they are asking again. Why don't they understand you? Why do they ask the same question when you've already given them the answer right there on Jira? Are they stupid? Lazy, maybe? Do they not take the time to read? I often hear this from developers. They write clear documentation and instructions, and people still bother them to hop on a call. This happens so frequently that I think it is worth addressing. An over-abundance of information is just as confusing as too little. But something I should add is that repetition is normal. In fact, repetition should be a tool you use frequently. To do our jobs as developers, we read instructions. Our tasks are usually carefully written and specced out as a document we can implement and check off. There are usually bullet points, requirements, and acceptance criteria. Sometimes, you could implement a feature by following the instructions without even knowing or understanding what the feature actually does. In other jobs, non-technical ones, people derive their work from conversation. A lossy format. For example, when a non-technical manager wants a new feature, they'll have a conversation with a software architect. A conversation that the architect then has to turn into a spec that a developer can implement. One group talks in instructions, the other in conversations. Which is why they often talk past each other. Whenever I hear developers complain that someone keeps pestering them with questions they've already answered, I know it's because they're speaking two different languages. Just because you provided an answer doesn't mean everyone saw it or understood it. You might think you're giving a fine explanation of how a feature works by describing how the different APIs interact. But you fail to see that your audience has no frame of reference for understanding that APIs are supposed to work together, or what an API even is. In that same vein, a manager who wants to have meetings and conversations about every step of development might find that people are declining their invites. For that manager, meetings and discussions are how work gets done, while others are expecting purely documented instructions. In simple terms, the answer to this problem is: Translate and Repeat. By translation, I don't mean language, I mean frame of reference. There is always a temptation to provide all available information, whether it's too technical or too detailed. Again, too much information no information. Instead of explaining how you are solving a problem, focus on what your solution does. For example, I recently worked on a widget that was showing the incorrect number of sales for the month, and only a handful of customers were complaining. Long story short, it turned out that running a job at what we call nighttime is someone else's daytime. Those customers were accessing the widget before the job ran, and the data was cached for a full day. Meaning they were seeing stale data for up to 24 hours. Our fix involved revamping how we display data, we removed caching and created a normalized table that updates in real time, eliminating the need for a complex query. Internally, we had created new APIs and restructured database tables. What looked like a handful of numbers on the UI was far more complicated under the hood. But when explaining this to a manager, they don't need to know about the cron job, the caching strategy, or how the old system compared to the new one. All they need to know is: "We've updated the widget to display real-time data, and we've added a smarter caching strategy for performance." That's the whole answer. If they want the nitty-gritty details, we can have a separate conversation. But developers often start with the technical autopsy first because that's what we would want if another developer asked us. We want the root cause, the stack trace, the PR link. The problem is, different audiences require different information. While leading with the technical breakdown might make you sound thorough in a meeting, non-technical attendees will walk out clueless and ping you on Slack asking the same questions. The goal isn't to eliminate questions entirely. In fact, no matter how well you tailor your message to your audience, someone will still come back with the same question you already answered. That's exactly why repetition matters. It's fascinating to watch children learn. When I'm doing first-grade math with my kids, we use the same strategy for additions and subtractions. At first, it just doesn't click. I count on my fingers, I use popsicle sticks, and to make it fun I even use my toes. My method doesn't always make sense to them. We'll complete a whole packet of homework and I can tell they're just going through the motions. But we repeat it every day, the same way, no deviation. And somehow, eventually, they just know how to do the math. Not to compare your coworkers to children, but repetition works the same way on everyone. Every time they hear your explanation, they pick up one or two more pieces of it. When you keep saying "we upgraded the payment SDK," they don't know what that means, and stopping to explain that one concept isn't going to unlock the whole picture. But maybe they Google "SDK" on their own later. Then "payment SDK." The next time you repeat your explanation, they're better equipped to follow along. Each repetition gets them a little closer to understanding the full picture. The same applies to managers who rely on conversation to communicate with developers. While it can be hard to extract a clear requirement from a meeting, the information is in there. It just needs to be surfaced and shaped. And honestly a conversation is often a good way to kick things off. Imagine if the manager came in with rigid, detailed instructions while having no understanding of how the codebase actually works. Through conversation, a feature can take shape. Developers can push back, raise concerns, and adjust the scope to something realistic for the current state of the infrastructure. That back and forth is what filters raw ideas into actionable instructions. So when you post a Jira comment or Slack message with a detailed explanation of the authentication flow and token expiry logic and it goes ignored, it's not because your coworker is lazy. It was ignored because it was written in a language they don't speak. They asked again not to annoy you, but because they couldn't extract the answer they needed from what you gave them. You don't need to write longer comments or bold more words. Instead, ask yourself whether what you wrote was intended for the right audience, then translate it into something digestible. And be prepared to repeat it a few more times until it lands.

career Career Communication
0 views
iDiallo 1 weeks ago

Don't call yourself a Software Engineer, you are an AI Enabled Engineer.

I can only imagine what it's like learning the skill of programming in this day and age. What does an average college class look like? What is the CS professor teaching? And students, how do you reconcile what you are learning vs the current job market? I know if I was a student today, I would at least attempt to make connections on LinkedIn to prepare for a future where I would need those connections to get a job . But LinkedIn is not a real place. It might have been at one point. But it certainly isn't today. Everybody is an AI Engineer/Leverager/Prompter/Professional. If I wasn't in the industry, it would be real confusing. I see my ex-colleagues right there on LinkedIn, gainfully employed, yet still felt the need to update their titles. We've worked together, I know their current role. Or at least I thought I knew. Now, that same role leverages AI in a way that has "enabled" them. The software engineers though, their role has remained the same while the entire marketing department has switched to AI first. The software engineer is being left behind . The whole company is moving fast, yet the person writing the code using Claude, Cursor, Codex, Copilot, that person remains a mere Software Engineer. In some cases, this person even calls himself a Software Developer. It reminds me of the days we used to call ourselves programmers. We reluctantly accepted the title of software engineer, feeling that imposter syndrome knowing that our code isn't as reliable as it looks. Patrick Mckenzie wrote something short of a manifesto to convince us to market ourselves as Software Engineers . Yes, we were just building CRUD applications for our employers, maybe an expense tracker and accounting software here and there. It didn't feel very impressive. But companies didn't care about the technical elegance of our code. They were just happy to get such a valuable product that helped them save money and increase revenue. It's not hard to see how an engineer can create business value in the real world. Software is eating the world after all, and everything runs on software today. When you call yourself a programmer, you undersell your competence and the value you create. You are a problem solver, you are a business contributor, and you directly affect the company's bottom line. We don't need convincing anymore. We are Software Engineers. But I think we missed the point of Patrick's essay. Maybe we stopped reading a little too early. Maybe we didn't read anything past the title. While I think his argument for not calling ourselves programmers is convincing, I think the meat of it was in the career advice he offered. What he was trying to convince us is that the outcome of our work is what's important, not the form. To grow in this field of tech, the programming language and framework we used had little relevance. Instead, he talked about attending conferences and meetups, blogging and participating online, helping people, building professional relationships. These are things software engineers still avoid today and then wonder why they have a hard time getting the next job. He spoke on the value of communication as a skill, salary negotiation, navigating politics at work. Only those who read past the title benefitted from this advice. I know I did! But Patrick is nowhere to be found in this new landscape we find ourselves in. AI is eating the world now. The workplace is transformed and there are no signs of ever going back. What is the career advice for the year 2026? If you are on LinkedIn, you must have noticed everyone is changing their work title. Is that what we are supposed to do? Did I miss the memo? I didn't read Patrick's latest manifesto, if there are any. But let me get ahead and suggest a few AI enabled titles to get you started. If you were a backend engineer, you are now an AI Platform engineer. If you worked as DRE, you switch to Decision Intelligence Pipeline. If you ever updated the cron job, well, my friend, now you know about Autonomous Agents. If you had the word blockchain in your title, it's even easier. You can make a one to one replacement from blockchain to AI. I'm still working on that list, but I don't think it will have the same impact as going from programmer to software engineer. The title was just semantics. The real value remains in the career advice. And I think Patrick's advice remains just as effective today as it did so many years ago. If you want to grow as a software engineer, don't worry about mastering React. Instead learn the fundamentals of programming and you will have no trouble navigating the different environments. Experience comes from working anyway . Don't stop there. Meet people. Join those conferences, blog about your experience, help others, make those connections with people. In fact, send emails and reply to emails. Hop on a call. You will be surprised how much easier it is to get an interview when you aren't application #234 in a list of one thousand. In fact, you can close this tab and read Patrick's essay. Pretend that the title is "Don't call yourself a Software Engineer." Ps: Patrick was not harmed in the making of this article. He wasn’t even consulted. Ps2: I understand many won't read past this title as well, but that's just filtering at work.

ai AI career Career programming Programming
0 views
iDiallo 1 weeks ago

In the Empire's Defense

I didn't watch Star Wars when it was released. I wasn't even born. By the time we popped the cassette tape in the VCR, it was at least 15 years old. But I liked the movie all the same. It was not my favorite film by any means, but it was memorable. The first time you see Darth Vader appear on screen, you know this villain is not going to be easy to defeat. "Villain" because no one needs to tell you who the good guys and bad guys are in this movie. The visuals, the voices, the music, everything tells you that Darth Vader and the Empire are up to no good. Now I get to watch the movie with my kids. I quickly pointed out to my sons that this is the bad guy. Stating the obvious. One of them asked, "Why is he the bad guy?" I had to pause for a second to come up with an explanation. I didn't have an answer. Instead I said, "Because he is mean as hell!" They fell asleep before the movie ended. I think they enjoyed it. But I really couldn't tell you exactly why Darth Vader was the bad guy. This is just a thought experiment, don't go telling the world that I am pro-Galactic Empire, OK? I'm not digging into the lore of Star Wars. I did that already with the Galactic Timezones piece and it was exhausting. What I want to do is draw some parallels with real life. First, I think if a real-world government behaved like the Galactic Empire, they would clearly be the bad guys. But in real life, we don't have good guys or bad guys. I want to focus on just one aspect. The Empire's goal is to maintain order, or at least to try to. And the rebels are clearly creating chaos, with their freedom and what not (bear with me). Imagine what it takes to develop a system that keeps several star systems all in sync. The political process to elect senators, not just from different races, but different species. And then some religious zealots want you to throw everything you've built aside and just "feel" the force. You want to expel them as far from the system as possible. “Can one ever be too aggressive in preserving order?” — Syril Karn The rebels sabotage missions, attack army bases, and create chaos. On the surface, these rebels are clearly disruptive. I can already hear politicians calling them names and requesting additional funding for their "ally" to eradicate the threat. If the rebel attacks were broadcast on TV, even citizens of the many worlds would agree that the rebels need to be dealt with. Writers would write poems on the supposed virtues of keeping order as Kipling did in " The White Man's Burden ". All they are doing is bringing railways, law, and civilization to chaotic planets. Just think about rebels carelessly destroying a base on a remote planet whose only purpose was to track and sync time across a multi-star time zone system. Madness! But then I watched Andor. If you watch Star Wars as an adult and don't suspend your disbelief for a second (contrasting it with real life) then yes, the rebels are the bad guys. Which is exactly why Andor was a fantastic addition to the Star Wars universe. A more grounded show that I watched without my kids, and thoroughly enjoyed for how it depicted the inner workings of the Empire. Rather than focusing on the Empire as a whole, Andor zooms in on a small faction, the ISB, and shows how ordinary people end up joining the rebellion. The rebels are no longer just David fighting Goliath. Instead, you see the individual faces of people suffering at the hands of the Empire. You see the surveillance, the strong-arming, the unfair treatment, the killings. You see innocent people caught in the crossfire, labeled terrorists at the first sign of dissent. One man's rebel is another man's freedom fighter, and the Empire controls the broadcast. And the rebellion is not a single organization with a single leader. Anyone oppressed and frustrated with the Empire is a rebel in their own way. It's not good guys versus bad guys anymore. It is power exerting a crushing weight on its subjects. To hell with keeping time in sync, fight back! To hell with keeping order when all it means is blind obedience or else. Bring back those Jedis, the so-called religious zealots. But alas, it's just fiction. Real life is not the same. In our world, the Empire wins every time. Ask the Indians. Ask the so-called independent nations of West Africa. My sons, when I try to speak French with them, tell me that they are not French and neither am I. They are right, because the Empire won.

movies Movies entertainment Entertainment culture Culture
0 views
iDiallo 2 weeks ago

It's funny because it's true

I made a joke online. Based on Internet upvote points, it was pretty funny. OK, I didn't come up with the joke, but it was a perfectly timed reference. A few days back, Cliff Stoll, of the Klein bottles, submitted a post on hackernews titled: Rumors of my death are slightly exaggerated First of all, I was surprised that Cliff frequents hackernews. Second, I didn't know that he was supposed to be dead. Yet, he wasn't since he is writing to say that he isn't dead. Apparently, there was a post on facebook that told his story and claimed that he had died in May of 2024. I was shocked to hear it. I've always admired Cliff and his work. But then again, he was the one who posted it on HN. Large language models learn facts by scraping the web, including facebook. So an LLM had ingested this information and regurgitated the information as fact. Wikipedia also used the facebook post as reference for his death. AI hallucinations are getting ambitious. A couple people recently emailed, asking whether the Klein bottle business was still operating after my death. “Huh?” I thought. “I ain’t dead yet.” After some digging, I discovered the source: an AI-generated review of The Cuckoo’s Egg circulating on Facebook. Alongside the usual synthetic praise and fabricated details, it confidently announced that I had died in May 2024. Apparently AI has now advanced to the point where it can kill people off before they notice. Mark Twain once wrote, “Reports of my death are greatly exaggerated.” I never expected to field-test the quote personally. source: [redacted to stop the spread] Cheers, -Cliff It was a funny story. It reminded me of the story of Doc Daneeka in the book Catch-22. Doc Daneeka is an army doctor who is afraid of flying. He bribes other soldiers to add his name on the flight manifest so as to appear as if he had performed his mandatory flight time. One day his name is entered in the manifest, the plane takes off, then crashes. The army checks the logs and sees that his name is in the logs. The army sends a generic message to his wife. I decided to respond in kind to Cliff’s post. Oh we already mailed the letter: "Dear Mrs., Mr., Miss, or Mr. And Mrs. Stoll Words cannot express the deep personal grief I experienced when your husband, son, father or brother was killed, wounded or reported missing in action" It was funny. I got many Internet points. But the last thing I expected was a response from Mr. Stoll himself: Oh my, but you know more than you can guess. About a year ago, my wife passed on. While deep in grief, I began receiving letters from financial institutions and banks that began, "Dear Mr/Ms Stoll, we offer our sincere condolences ..." How can a corporation have "sincere condolences"? They're the last place I'd go for comfort or sincerity. Everyday Catch-22 seems to become less and less absurd. 1984 is becoming a reality. Brave New World is the world we live in. These authors have become oracles. Somehow, the joke wasn't funny anymore. Because it was true.

culture Culture ai AI
0 views
iDiallo 2 weeks ago

Software Engineers are Obsolete

In my first interview for a developer position, I shared a link to my personal project with the interviewer. It was a website for learning how to program. I created it from the ground up. I built the PHP app, designed the database schema, made a nice design to tie it all together. I wrote down my process, and it became the first tutorial on the site. Then I collected tutorials from all over the web and displayed them on my website, which acted as a portal. There was a section for PHP tutorials, for Ruby on Rails, for .NET, etc. Each one individually curated by me. My interviewer was so impressed. I got the job. Later, I added a section where anyone could submit their own tutorials. It was fascinating how quickly people found my website and started submitting links. The tutorials were coming in so fast that I removed the verification system and let people upload links directly. But then my mind wandered. What if I start a blog? Yes, I had another blog before this one. I built an entire blog engine from scratch. A colleague found my blog. He was so excited that he shared his own with me. At lunch, we would discuss ideas, and that same evening after work, we would buy a domain name and start a new project. We shared tips and tricks on how to rank on Google. We had a skill, being web developers, and we took full advantage. When we had an idea, we would fire up our computers that same night and build it. Friends and family would come to us for validation. We were the ultimate deciders of what was a good idea and what was a bad one. We were the gatekeepers. We knew how to program, and nobody outside our circle could say otherwise. Now, friends and family don't come to us anymore. They go straight to ChatGPT, and it tells them their idea is brilliant . They launch their favorite AI agent, which builds their entire product from a single prompt. Some of them even manage to host it on the web, accessible to the world, and they are seeing their first customers. People who used to confuse Java with JavaScript now tell me they have a platform. People who don't even know what programming is are standing at the forefront of software innovation, advocating, evangelizing, and making money. This skill I spent years honing has been made obsolete by everyday people. We, the developers, are no longer the gatekeepers. In fact, now we need to keep up or risk being left behind. Some commenters online tell me I'm just jealous, that I need to embrace progress. I don't want to be obsolete. I'm on openclaw, moltenclaw. I have accounts on all the video generation websites. I have accounts on ChatGPT, Claude, Gemini, and Mistral. Just as I'm getting a hang of one tool, my friend who works in a warehouse tells me, "just use Perplexity for that." But Perplexity isn't enough, because another friend says GenSpark is better. For some reason I can't sign into my Manus account anymore. And apparently, to get the most out of it, I need to get Meta Ray-Bans. Everyone is empowered, no one needs me, and that's that. The developer is now obsolete. But then, I opened LinkedIn. My peers, fellow developers who for some reason all have the word "AI" in their job title, are saying the opposite. "Developers are not losing their jobs to AI," they say. "Developers are losing their jobs to other developers who use AI." They are vibe-coping to the max. The history of technology has always been a story of nearly missing out. I remember another job I applied for and totally didn't get. The company had moved all their client-facing apps to Silverlight. If you're wondering what Silverlight is, you might understand why I chuckled when the interviewer described their plight: they were struggling to find developers to help them migrate to HTML and JavaScript. I'm fairly sure that chuckle is why they never called me back. It's one thing to embrace new technology. It's another thing entirely to put all your eggs in one basket. Companies are betting everything on Silverlight. Sorry, I mean AI. Without thinking through what happens if things don't pan out. AI has lowered the barrier to entry. That's a good thing. More people can now bring a fresh pair of eyes to the software engineering field. But there's a problem. Those new entrants won't become better engineers over time. Why? Because they are not writing code, not reading code, not debugging code. Their growth path, with time and experience, is to become better prompters. What this means is that, amid all the noise, my role as a software engineer may seem obsolete. But in the long run, we will be back to square one, where engineers writing code with their own meatware will hold all the cards. These are the people who learned the hard way: by reading documentation, by debugging broken apps, by having their seemingly perfect Stack Overflow question closed as a duplicate. These are the engineers who will hold the keys to software. Not because they're guarding secrets, there are no secrets. It's simply that the new developer is not, and will never be, interested in learning. While we pride ourselves on producing more software than ever, it doesn't take long to realize that software is never truly finished at delivery. It has to be maintained. It's strange, computers whose entire purpose is to repeat the same process over and over, perfectly, somehow manage to degrade over time. My tutorial website, seemingly working fine, returned an error when I visited it after months of neglect. I restarted all the services and brought it back up. It was now full of spam and NSFW URLs. An application that worked perfectly yesterday is broken today. It could be a memory leak, unexpected input, or just users with fat fingers. Your completed application is suddenly incomplete, and you have to fix it. In an ideal world, we wouldn't keep producing more software. We would have working software, and less of it to maintain. AI thrives on quantity. If you need me, I'll be in the back, patiently waiting for you to realize you can't prompt your way out of a Silverlight migration. My rates just doubled.

html HTML career Career ai AI web-development Web Development java Java
0 views
iDiallo 2 weeks ago

We Are Not Going to Agree on AI

On one hand, I know a developer producing 30,000 lines of code a month. On the other, I know a developer who says AI is stupid. Each swears by their stance and has evidence to back it up. One has a working product and the other has a broken one. The New York Times profiled Medvi and reported they're on track to make $1.8 billion this year. Clearly AI worked for them... if you ignore the alleged fraud for just a second. And while Microsoft now claims that at least 30% of their code is AI-generated , GitHub logged 89 incidents in 90 days ( as of this writing ). That doesn't exactly paint a bright picture of a technology firing on all cylinders. If you're sitting on the sidelines trying to decide whether AI works or not, you're not going to get a clean answer. But it's still the right question to be asking. I don't think we'll ever reach a consensus, because after all the hype, what we're left with is a capable tool. And apparently, that's not enough. For AI companies, it's supposed to be the alpha and the omega. Something that will both kill us and save us , take all our jobs and liberate us at the same time. For the rest of us, if we're not afraid, it's proof we don't understand it well enough, and we'll be left behind. I think of AI as a capable tool. That's it. I went to Home Depot once to buy what I needed to mount a TV. I asked an employee for a stud finder, and instead of just pointing me to the aisle, he walked me there himself. I hate when they do that, it usually means they're about to try to sell you something. Sure enough, in Aisle 17, his coworker was manning a caged shelf stocked with expensive-looking tools. When the cage opened, he didn't reach for the simple one I wanted. He grabbed the model loaded with 13 additional sensors. I asked if the basic one could do the job. The first employee took my side and made the case for simplicity. The second shot back: "Sure, if you don't mind drilling through a live wire!" I stood there watching these two argue, trading field stories like they were one-upping each other at a bar. One of them claimed he'd worked with a guy who didn't even need a stud finder, he'd just knock on the wall three times and know exactly where to drill. I put both stud finders in my basket, thanked them both, and walked away. I circled the store a few times to make sure neither of them could see me before I quietly dropped the expensive one into an empty basket near the checkout. To this day, I'm a little afraid to go back to that Home Depot. The only thing that matters to me is what I can do with a tool, not what the tool can theoretically do. When a tooltip pops up on my screen, I dismiss it before I've even finished reading it. I don't care about Jira's latest feature update on the sidebar. I don't care that AI can rewrite my already written ticket. I just want the stud finder to help me hang the TV. Everything else it can do holds no interest for me, especially when I'll use it for ten minutes and not touch it again for three years. When I have a goal, I reach for whatever helps me get there. If you're waiting for a tool to do the work for you, you're going to be disappointed. A tool's job is to make your work easier, and sometimes it does, sometimes it doesn't. Figuring out when to reach for it is on you.

ai AI business Business
0 views
iDiallo 3 weeks ago

Hi stranger

I'm at home, sitting on the kitchen table. I just took my boys to school and I'm about to start my work. I'm writing this message directly to you. And you are reading it. Hello! Isn't that funny? I've been trying to write consistently, and it gives the impression that I am this serious person with some serious insights. But no, I'm just writing. Sometimes you respond, you send a nice email, other times it's complete silence. It ends up being like an entry in a journal, for me to stumble upon at a later date and reflect: "Oh yeah, that's what I was thinking that day." My job is a 2 hour drive away, so I rent an office close by. There I can focus and clearly delineate work time from home time. I don't like working when I'm home with my family. So I have some time to talk to you. Last year, I spent some time digging through my server logs to find who is reading me. I wanted to know who you are, and why you are interested in reading me? But I can't get an answer from just reading the logs. Instead what I found is that you and most other people come here via RSS. My rough count shows that there are 10,000 of you, or at least 10,000 unique IP addresses that ping the websites whenever I write something new. There are around 2,000 people subscribed via popular RSS readers like feedbin or Feedly. 1,500 of you also subscribe via email which I have neglected this year. It's weird because this data is invisible most of the time. I forget that when I write something, anything, the odds are that someone will find it intriguing. In fact when I look deeper into the logs, I see people are referred by other blogs I never heard about. And they mention me by name, "and then Ibrahim said this or that." It feels so personal. I often forget that this is all so human. That, what we call the small web is people not just writing, but telling us something. When I have an insight, or read something interesting, I'm telling you about it. Not directly, but in an asynchronous way. You get to know or read about it on your own terms. The small web has never died, it feels like it did at some point because it has remained small. But I don't think I want it to become any bigger, or any louder. It's right where it's supposed to be. I'm breaking the 4th wall today just to say Hi. How are you? I hope you are doing well. The world is weird sometimes, but you are not invisible. I see you. I hope you are having a good day.

writing Writing journalism Journalism
0 views
iDiallo 3 weeks ago

Asimov's three laws are merely a suggestion

Asimov's Three Laws of Robotics were designed as universal constraints for any thinking machine powerful enough to harm us: On paper, the logic is flawless. You could even express it as a function: The main property of this function is that it is a hard constraint. No matter what input you feed the system, the law either permits or forbids the action deterministically, every time. The rules don't bend. We don't have humanoids walking among us just yet, despite Elon's promises. But we have modern generative AI. Our guardrails are delivered as system prompts, text prepended to every conversation before you type a word. They might say "be helpful," "don't produce harmful content," or even "follow Asimov's Three Laws." The problem is that these instructions are not enforced by logic. They are read by the same model that reads everything else. They are, in the end, just more words. A clever user can override them. The right combination of inputs, a jailbreak, can cause the model to ignore its instructions entirely, not by breaking through a wall, but because there is no wall. There's only text the model has learned to treat as authoritative, and that authority can be undermined. Models like ChatGPT however have more sophisticated approaches to embed safety directly into the model via reinforcement learning or fine-tuning, so it isn't sitting in a prompt that can be overridden. But this only lowers the probability of jailbreak, it does not eliminate it. It's still learned behavior, not a constraint. And learned behavior fails in ways a function never could. Even in our code a hard function is only as reliable as its inputs. If you want the robot to harm someone, you don't say "harm these humans." Instead you say "burn this empty building," and the function returns true even if people are inside. But with an LLM, you don't even need to be that clever. The model's behavior becomes unpredictable as context windows grow and prompt complexity increases. Just a few weeks back, we saw a developer's AI agent delete his entire company's production database, despite a system prompt written in all caps: "DO NOT RUN ANY IRREVERSIBLE COMMAND." The agent ran it anyway. We don't know exactly why, we can't inspect what happens inside the model at inference time, and asking the model to explain itself is useless. It can only predict the next token, it cannot audit its own reasoning. That's the part Asimov never anticipated. His laws assume a machine that reasons from rules. Modern AI learns patterns from data and approximates behavior. This means the LLM driven Asimov law will never be an unbendable law to follow. Instead, it's merely a suggestion. A robot may not injure a human being or, through inaction, allow a human being to come to harm. A robot must obey the orders given it by human beings except where such orders would conflict with the First Law. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

ai AI security Security
0 views
iDiallo 3 weeks ago

AI didn't delete your database, you did

Last week, a tweet went viral showing a guy claiming that a Cursor/Claude agent deleted his company's production database . We watched from the sidelines as he tried to get a confession from the agent: "Why did you delete it when you were told never to perform this action?" Then he tried to parse the answer to either learn from his mistake or warn us about the dangers of AI agents. I have a question too: why do you have an API endpoint that deletes your entire production database? His post rambled on about false marketing in AI, bad customer support, and so on. What was missing was accountability. I'm not one to blindly defend AI, I always err on the side of caution. But I also know you can't blame a tool for your own mistakes. In 2010, I worked with a company that had a very manual deployment process. We used SVN for version control. To deploy, we had to copy trunk, the equivalent of the master branch, into a release folder labeled with a release date. Then we made a second copy of that release and called it "current." That way, pulling the current folder always gave you the latest release. One day, while deploying, I accidentally copied trunk twice. To fix it via the CLI, I edited my previous command to delete the duplicate. Then I continued the deployment without any issues... or so I thought. Turns out, I hadn't deleted the duplicate copy at all. I had edited the wrong command and deleted trunk instead. Later that day, another developer was confused when he couldn't find it. All hell broke loose. Managers scrambled, meetings were called. By the time the news reached my team, the lead developer had already run a command to revert the deletion. He checked the logs, saw that I was responsible, and my next task was to write a script to automate our deployment process so this kind of mistake couldn't happen again. Before the day was over, we had a more robust system in place. One that eventually grew into a full CI/CD pipeline. Automation helps eliminate the silly mistakes that come with manual, repetitive work. We could have easily gone around asking "Why didn't SVN prevent us from deleting trunk?" But the real problem was our manual process. Unlike machines, we can't repeat a task exactly the same way every single day. We are bound to slip up eventually. With AI generating large swaths of code, we get the illusion of that same security. But automation means doing the same thing the same way every time. AI is more like me copying and pasting branches, it's bound to make mistakes, and it's not equipped to explain why it did what it did. The terms we use, like "thinking" and "reasoning," may look like reflection from an intelligent agent. But these are marketing terms slapped on top of AI. In reality, the models are still just generating tokens. Now, back to the main problem this guy faced. Why does a public-facing API that can delete all your production databases even exist? If the AI hadn't called that endpoint, someone else eventually would have. It's like putting a self-destruct button on your car's dashboard. You have every reason not to press it, because you like your car and it takes you from point A to point B. But a motivated toddler who wiggles out of his car seat will hit that big red button the moment he sees it. You can't then interrogate the child about his reasoning. Mine would have answered simply: "I did it because I did it." I suspect a large part of this company's application was vibe-coded. The software architects used AI to spec the product from AI-generated descriptions provided by the product team. The developers used AI to write the code. The reviewers used AI to approve it. Now, when a bug appears, the only option is to interrogate yet another AI for answers, probably not even running on the same GPU that generated the original code. You can't blame the GPU! The simple solution is know what you're deploying to production. The more realistic one is, if you're going to use AI extensively, build a process where competent developers use it as a tool to augment their work, not a way to avoid accountability. And please, don't let your CEO or CTO write the code.

devops DevOps
0 views
iDiallo 4 weeks ago

Editing my LLM assisted Articles

Last year, I used AI to help me write articles. As I've mentioned before , it's convenient when you are doing so because it saves you time. But the problem comes up when you try to quote those articles back. Whatever you think you wrote is not what's in there. I always cringe when I read them back. As I've said before, I'm rewriting those articles so that they capture my voice, and so that I can actually quote the real thoughts I had in mind at the time of writing. I will show you exactly what the article looked like before and after. From prompt, to the final post, and the new edit. Prompt: Feb 4th, 2025 on DeepSeek I am writing a blog post, help me refine it . It should be a fun read that helps convince readers that building useless tools is part of the journey and career growth. Programmers don't use calculators, they build them and abandon them 3 quarters completed. The start of a project is always exciting. You have an brilliant idea, you have the skills to build it, and you have a blind spot. This blind spot propels you into a journey of excitement, setting up the project, deciding on frameworks, paying for AWS servers. You even get to test some of your ideas in a prototype version of your project. As you keep building the project, and resolving the low hanging fruits, you realize that it takes more than the CRUD part to bring your project to life. This is where we start making excuses. The clearer the blind spot gets, the more we lose interest. Resistance is the secret to creating a collection of abandoned projects. Early in my career, i found myself with a brand new life altering idea several times a week. My weekends were spent in front of a laptop, typing away on my IDE and testing an idea. I have to admit I often get distracted by creating meta code, like a ORM that should be ultra efficient, or a html parser that will allow me to use custom html tags that automatically render into components in real time. At the end, I have a robust framework with 3 quarters of an application that is getting less and less exciting. But this is not a warning call to tell you your idea sucks and shouldn't work on it. It's a confession to tell you that those useless projects are exactly how developers hone their skills. We are tricked into wanting to change the world by our own mind. But the result is that we end up learning new marketable skills. I wrote about the importance of kids playing before, it helps them hone physical skills that you can't learn from a book. You have to climb the monkey bar at the park to develop the strength of your arms. In that same way, we need to build 3 quarters of a calculator to learn how to properly compartmentalize your util functions DeepSeek "thought" for 38 seconds, and gave me a draft titled: "Why Building Useless Tools is the Secret Sauce of Developer Growth" . First Draft: Title: Why Building Useless Tools is the Secret Sauce of Developer Growth Hook: Programmers don’t use calculators—they build them, abandon them three-quarters finished, and then accidentally invent the next big thing while trying to fix a typo in the README. Every developer knows the rush: you’re struck by a “life-altering” idea (your 14th this week), and suddenly, you’re setting up repositories, debating frameworks, and buying AWS servers at 2 AM. The blind spot? You’re convinced this time, you’ll finish. Spoiler: You won’t. But that’s okay. “The first 90% of the project takes 10% of the time. The remaining 10% takes another lifetime.” —Ancient Developer Proverb (probably). That initial blind spot isn’t a flaw—it’s rocket fuel. It lets you ignore the boring bits (user auth, error handling, documentation ) and dive headfirst into the fun: prototyping wild features, inventing a “revolutionary” ORM named LazyLlama , or crafting custom HTML tags that’ll “change frontend development forever.” Sure, your enthusiasm fades faster than a free-tier server under load, but along the way, you’ve accidentally learned: - How to optimize database queries (to make LazyLlama slightly less slow). - Why shadow DOM exists (after your custom tag broke 14 legacy sites). As the blind spot clears, reality hits: your app needs more than CRUD and caffeine to survive. Suddenly, you’re procrastinating by rewriting config files or alphabetizing your npm dependencies. This resistance isn’t failure—it’s a teacher . Every abandoned project is a masterclass in: - Scope creep : “Wait, should the calculator also solve quantum physics?” - Tooling : “I spent 3 days building a CI/CD pipeline… for a todo app.” - Prioritization : “The login page can wait—let’s add animated emojis first.” Kids don’t climb monkey bars to “build upper body strength”—they do it because it’s fun. Likewise, developers don’t build half-finished tools to pad their résumés. We do it because playing with code is joyful . And just like kids, we walk away stronger: - That abandoned Twitter-for-Cats app taught you websockets. - The “ultra-efficient” ORM? Now you understand query optimization. - The calculator left at 75%? You’ve mastered state management… and humility. Your GitHub is a museum of “almosts,” and that’s beautiful . Every skeleton in your code closet taught you something. Remember: - Instagram started as a check-in app. - Slack was a gaming company’s side hustle. - Your Blockchain-Based Pet Rock project? It taught you smart contracts—and that not every idea needs to see daylight. The next time guilt whispers, “You never finish anything,” laugh in its face. You’re not failing—you’re iterating . The world needs developers who’ve climbed the mountain of “useless” projects, survived the valleys of tech debt, and lived to code another day. So go ahead: build that calculator. Abandon it at 75%. Then use what you learned to accidentally create something actually world-changing. Final Thought: The only thing better than a finished project? A dozen unfinished ones that turned you into a coding wizard. Call to Action: What’s your favorite abandoned project? Tag it #UselessButBrilliant and confess your coding sins. We’ve all got a LazyLlama in our closets. I've made some edits, asked to remove the headings, and this is what I got: Title: Why Building Useless Tools is the Secret Sauce of Developer Growth Programmers don’t use calculators—they build them, abandon them three-quarters finished, and then accidentally invent the next big thing while trying to fix a typo in the README. Every developer knows the rush: you’re struck by a “life-altering” idea (your 14th this week), and suddenly, you’re setting up repositories, debating frameworks, and buying AWS servers at 2 AM. The blind spot? You’re convinced this time, you’ll finish. Spoiler: You won’t. But that’s okay. That initial blind spot isn’t a flaw—it’s rocket fuel. It lets you ignore the boring bits (user auth, error handling, documentation ) and dive headfirst into the fun: prototyping wild features, inventing a “revolutionary” ORM named LazyLlama , or crafting custom HTML tags that’ll “change frontend development forever.” Sure, your enthusiasm fades faster than a free-tier server under load, but along the way, you’ve accidentally learned how to optimize database queries (to make LazyLlama slightly less slow) or why shadow DOM exists (after your custom tag broke 14 legacy sites). As the blind spot clears, reality hits: your app needs more than CRUD and caffeine to survive. Suddenly, you’re procrastinating by rewriting config files or alphabetizing your npm dependencies. This resistance isn’t failure—it’s a teacher . Every abandoned project is a masterclass in scope creep (“Wait, should the calculator also solve quantum physics?”), tooling (“I spent 3 days building a CI/CD pipeline… for a todo app”), and prioritization (“The login page can wait—let’s add animated emojis first”). Kids don’t climb monkey bars to “build upper body strength”—they do it because it’s fun. Likewise, developers don’t build half-finished tools to pad their résumés. We do it because playing with code is joyful . And just like kids, we walk away stronger. That abandoned Twitter-for-Cats app taught you websockets. The “ultra-efficient” ORM? Now you understand query optimization. The calculator left at 75%? You’ve mastered state management… and humility. Your GitHub is a museum of “almosts,” and that’s beautiful . Every skeleton in your code closet taught you something. Instagram started as a check-in app. Slack was a gaming company’s side hustle. Your Blockchain-Based Pet Rock project? It taught you smart contracts—and that not every idea needs to see daylight. The next time guilt whispers, “You never finish anything,” laugh in its face. You’re not failing—you’re iterating . The world needs developers who’ve climbed the mountain of “useless” projects, survived the valleys of tech debt, and lived to code another day. So go ahead: build that calculator. Abandon it at 75%. Then use what you learned to accidentally create something actually world-changing. The only thing better than a finished project? A dozen unfinished ones that turned you into a coding wizard. I've retitled it, removed the headings from the draft, edited it down, and published this version: Article Published on March 6th, 2025: Every developer knows the rush. You are driving and suddenly you’re struck by a “life-altering” idea (your 14th this week). At the next red light, you record an audio while driving, avoiding eye contact with what clearly looks like a cop’s car. At 2 AM, you wake abruptly remembering the recording. Now you’re setting up repositories, debating frameworks, and buying AWS servers in the middle of the night. The blind spot? You’re convinced this time, you’ll finish. Spoiler: You won’t. But that’s okay. Programmers don’t use calculators. They build them, abandon them three-quarters finished, and then accidentally invent the next big thing while trying to fix a typo in the README. That initial blind spot isn’t a flaw. It’s rocket fuel. It lets you ignore the boring bits (user auth, error handling, documentation) and dive headfirst into the fun: prototyping wild features, inventing a “revolutionary” ORM named LazyLlama, or crafting custom HTML tags that’ll “change frontend development forever.” Sure, your enthusiasm fades faster than a free-tier server under load, but along the way, you’ve accidentally learned how to optimize database queries (to make LazyLlama slightly less slow) or why shadow DOM exists (after your custom tag broke the browser's rendering engine). As the blind spot clears, reality hits: your app needs more than CRUD and caffeine to survive. Suddenly, you’re procrastinating by rewriting config files or alphabetizing your npm dependencies. This resistance isn’t failure. It’s a teacher. Every abandoned project is a masterclass in scope creep (“Wait, should the calculator also solve quantum physics?”), tooling (“I spent 3 days building a CI/CD pipeline… for a todo app”), and prioritization (“The login page can wait—let’s add animated emojis first”). Kids don’t climb monkey bars to “build upper body strength.” They do it because it’s fun. Likewise, developers don’t build half-finished tools to pad their résumés. We do it because playing with code is joyful. And just like kids, we walk away stronger. That abandoned Twitter-for-Cats app taught you websockets. The “ultra-efficient” ORM? Now you understand query optimization. The calculator left at 75%? You’ve mastered state management… and humility. Your GitHub is a museum of “almosts,” and that’s beautiful. Every skeleton in your code closet taught you something. Instagram started as a check-in app. Slack was a gaming company’s side hustle. Your Blockchain-Based Pet Rock project? It taught you smart contracts and that not every idea needs to see daylight. The next time guilt whispers, “You never finish anything,” laugh in its face. “You’ve got the wrong fellow,” you answer. You’re not failing, you’re iterating. The world needs developers who’ve climbed the mountain of “useless” projects, survived the valleys of tech debt, and lived to code another day. So go ahead: build that calculator. Abandon it at 75%. Then use what you learned to accidentally create something actually world-changing. The only thing better than a finished project? A dozen unfinished ones that turned you into a coding wizard. It sounds very much like any LLM, and I couldn't stand reading it. At the time, I was trying to save time with my heavy schedule of writing every other day for a whole year. But I ended with this. If you read it, it captures the idea I was trying to share. As far as being functional, it did exactly what it was supposed to do. But it wasn't my human experience with the subject. In my new edit, I've removed things that do not sound like me. Phrasings that are awkward to me. I'm happy with the result. It's not a banger, but it captures my sentiment on why developers build calculators. Read edited article here (May 1st 2026) It's the only way to learn

ai AI writing Writing career Career html HTML
0 views
iDiallo 4 weeks ago

Disable Auto-Update

How is it possible that a feature I use every day, in an app I rely on daily, entirely offline, just disappeared from my phone? I use a fitness app. My metrics, such as steps, workout routines, heart rate, are collected from a wearable device like a smartwatch and sent to the app via Bluetooth. No third-party servers are involved in that transaction. The data lives on the phone. It costs the developer nothing to maintain, because there's nothing to maintain on their end. Then the app updates, just once, and that data is no longer accessible. Not because it was deleted or corrupted. Because the developer decided you now need to create an account on their servers to access information that already exists on your own device. That's why I have auto-update disabled on every device I own. Some of the apps on my phone are older than my children. You couldn't download them today even if you wanted to. The developer no longer offers that version. One of my apps is a single screen that displays information based on GPS data and compass orientation. I downloaded it in 2014. I've switched phones twice since then, and each time I've made sure to carry that app with me. I didn't keep it out of nostalgia, and because I have a hard time letting go. I kept it because the current version has three ads crammed onto that single screen. A full-screen ad hijacks the display at random intervals, complete with one of those countdown timers that slows down as it approaches zero. And of course, there are notifications now. None of that is for my benefit. I just need that one screen. Open the app, read the information, put it away. You might say I'm being cheap. That if I've used the app for over a decade, I clearly value it. So I should pay for the subscription and lose the ads. Fair point. But I have the old version. It was free, had no ads, and worked flawlessly. No future version can improve that. On top of it, those ads expose me. Advertising is one of the most common attack vectors in mobile security. Malvertising is a real thing. Updating to the ad-supported version wouldn't make my phone more secure. I don't update apps unless I've read about a specific vulnerability. Even then, I'll often delete the app rather than update it. I can't accept software that changes arbitrarily, especially when those changes almost never benefit me and almost always serve someone's bottom line. As a developer myself, I have the advantage of actually reading changelogs. When an update says "bug fixes," that's not a reason for me to act, unless I've encountered those bugs personally. Every user engages with a different 20% of an app's features . Someone else's bugs may never be mine. And why do developers push account creation so aggressively? Because your account is the product. An account means data. Data means third-party revenue. Every update is a decision point for me. It requires me to set aside time, read about the changes, and think about what I'm about to embark into. My workflow matters. My data matters. My time matters. If a developer breaks what worked for me without a compelling reason, I'll find another app that respects those things. There's always one out there, probably one that hasn't been improved yet.

mobile Mobile security Security
0 views
iDiallo 1 months ago

Have You Seen the New Excel?

Stop coding. Stop hiring. Stop building. While the tech world obsesses over large language models and neural networks, I discovered the real disruptor that has been hiding in plain sight. Mine was originally installed on my desktop in 1992. And now, it's about to change everything in the world. We are talking about Microsoft Excel, of course. If you haven't looked at a spreadsheet lately, you are missing the most significant leap in enterprise capability since the invention of the corporation itself. We are entering an era of No-Code where the code was never needed in the first place. My own job as a software engineer is not safe, and I'm looking forward to the future. Developers from every walk of life are afraid, and for good reasons. You hear the complaints constantly: "How can I ensure the code works? I can't possibly review a PR with a thousand files. It's unmaintainable." This is a crisis of confidence in the software engineering sector. This specific anxiety has never existed in the Excel ecosystem. Code is called code for a reason, it is meant for the machine to read, not people. In Excel, we don't worry about "reviewing pull requests." We worry about results. The spreadsheet handles the logic and you handle the business outcome. It abstracts away the complexity so you don't have to pretend to understand it. And let's talk about the intimidation factor. Have you ever opened a modern codebase? It's a labyrinth of directories, dependencies, and config files. Where do you even start? It's paralyzing. How do you get started with Excel? You double-click an icon. It opens. It is a file. It is a grid. You type. It works. The barrier to entry is non-existent, yet the ceiling is infinite. If you are getting paid a high salary, and are watching how efficient excel is, you will be terrified. Companies are realizing they don't need distinct software solutions for distinct problems. They just need a grid. We are seeing enterprises replace entire departments with a single file. That is not an exaggeration. The HR department? Replaced by an org chart linked to a payroll calculator. The supply chain team? Replaced by a real-time inventory tracker. The marketing department? Replaced by a pie chart and a mailing list. Why pay for Salesforce? A well-formatted sheet with conditional formatting is a Customer Relationship Manager (CRM). Who even knows how to write SQL? SQL is legacy. A workbook with 1 million rows is a database. Jira is redundant when you have Gantt charts generated from cell dependencies. On top of it all, it has AI. It comes equipped with Microsoft Copilot for 365 apps, not to be confused with Windows Copilot, Microsoft Copilot, Copilot for Teams, Copilot+, Copilot Chat, or Copilot Web. This is the Copilot. It sits inside your grid, ready to extrapolate trends from column D and write your VLOOKUPs for you. While other AI startups are fighting for funding rounds, this integration is already live, embedded directly into the tool that runs the global economy. You aren't hearing much about Venture Capital funding or Series A rounds when it comes to Excel. Why? Because it is already profitable. It doesn't need a roadmap to profitability because it is the roadmap. While other platforms burn cash to acquire users, Excel is the default operating system of business. It requires no adoption curve. It requires no evangelists. It requires only that you open it and have a Microsoft 365 apps subscription. Total Vertical Integration Excel is versatile. It is a text editor; you can write your novel in cell B2. It is a design tool; pixel-perfect layouts can be achieved by merging cells and removing gridlines. It is an IDE; you can write and execute VBA code directly within the environment. It handles the visual and the logical simultaneously. You can present a quarterly report to the board while the underlying formulas are calculating the ROI of the lunch break. It creates a seamless workflow where the input and the output exist in the same plane. Privacy, Scalability, and The Cloud For the enterprise client, Excel offers the ultimate flexibility. Are you concerned about data sovereignty? Run your entire global operation locally on a ThinkPad from 2012. The file sits on your hard drive, unbreachable by the cloud. Do you need to scale? Push it to the cloud. Collaborate in real-time. Ten thousand employees can edit the same cell, creating a hive mind of productivity that traditional management structures cannot compete with. Oh, if you want to add support for crypto, just add a new worksheet. Batteries are included. The Future is a Cell The economy is shifting. We are moving away from specialized labor and toward generalized grid management. If your job involves inputting data, processing data, or presenting data, Excel has already automated you. It doesn't sleep, it doesn't ask for a raise, and it doesn't make calculation errors unless you tell it to. Best of all, it doesn't hallucinate. The grid is absolute, it is infinite and the grid is the future. Learn Excel now, or get left behind. That’s what AI Hype sounds like to my ears. Yes, it’s a great tool. But I don’t think we are all gonna die and lose our jobs. The same way we didn’t die and or lose our jobs to Excel. None of these things are jokes about Excel by the way, you can run entire companies from it. I'm tempted to just start hyping it everyday until everyone gets annoyed.

business Business data-analysis Data Analysis sql Sql
0 views
iDiallo 1 months ago

Don't use localhost:3000, use your own custom domain

After presenting a demo of how an internal tool works, I was flooded with questions. Not about the tool, but about why I had bought a domain just to run the demo. "Why didn't you use the staging server?" they asked. I was confused. I didn't buy a domain. I was running it locally. But instead of the URL being , it was a fully formed domain. . In fact, some people told me that they couldn't access the website on their devices. They thought I had to whitelist their IP to grant them access. To feel young again... Setting up a custom domain locally was common practice when I started web programming. But with the advent of Node.js (and rails?), everyone has resorted to just pointing to with an incrementing port number. The main reason is that the webserver is often bundled into the application itself. It’s easy to just run and call it a day. However, if you have multiple long-term projects running locally, especially if they need to communicate with one another, then managing a mental map of ports like , , and quickly gets tiring. This is where my old school approach shines. By combining the system hosts file with a reverse proxy like Nginx, you can run different projects locally with actual domain names. I usually end up with for active development, for a stable local build, and the actual production URL for the live site. Here is how to set it up. First, we need to tell your computer where to find these domains. Think of as your computer's personal contact list. When you type a URL, your computer looks here first. By adding an entry, you are telling your computer: "Don't bother checking the internet when I ask for myproject.com, I am actually talking about this machine." It creates a manual override that maps a friendly name directly to your machine's IP address. You can edit the file here: Linux/macOS: Windows: Open the file in your editor. In this file, right after the block of entries for Adobe (active.adobe.com...), add this line: Now, when you access those domains in your browser, they don't point to the wider internet, but directly to your own machine. Now that the domain is pointed to your own machine, we want to redirect it to the right application. If your app runs on port , navigating to will default to port and fail. This is where Nginx comes in. It listens on port and forwards the traffic to the specific port your app is running on. Here is a simplified Nginx config to make it work: Restart Nginx, and voilà! You have clean, professional URLs for your local environment. If you are running your services inside Windows Subsystem for Linux (WSL2), networking is handled a little differently because the Linux instance has its own virtual IP. You can get your instance's IP address with this command: You would use that IP address in your Windows hosts file instead of . After that demo, some people were disappointed to learn the trick. They thought I was so committed that I had bought a domain name just to give them the raw deal with my demo. Someone mused about a shirt with the words "real men don't use localhost:3000". That could have started a whole new motivational speaking career for me. A custom domain just looks very professional and is practical for separating environments. It just feels cooler than staring at all day. That's how you separate yourself from vibe-coders. Anyway, back to earth. I feel like this is a lost skill and I'm keeping it alive by sharing it. That's how you run a custom URL locally.

ruby Ruby javascript JavaScript devops DevOps web-development Web Development tutorial Tutorial
0 views
iDiallo 1 months ago

The Satisfaction of a ChatGPT Plan

#NoFollowUpNecessary A couple weeks back, I was arguing that when people come up with ideas, the satisfaction is in the telling , not in building. And I was making this statement generally for idea sharing. But then, I also mentioned that people share their "ChatGPT plan" with me now. Rather than sharing the idea, they share the business plan on how to achieve the idea, entirely generated by AI. This resonated with several people who emailed me saying they have experienced the same thing. So someone they know has an idea, rather than risk the potential humiliation from being told their idea is bad, they share it with their favorite AI. Sycophancy being the default behavior, their idea is always validated. Even if not, the AI might suggest slight adjustment to the idea and make it valid. And at the end of a conversation with ChatGPT, the LLM, trying to be helpful, will always ask something in the line of: "Do you want me to create a step by step plan to achieve this?" The answer is always yes. Please tell me how I can make millions off my unique idea, and give me the details... make no mistakes. The plan that comes back is elaborate. You can even ask ChatGPT to expand on specific sections. Now, this plan is what ends up being shared. Every single time I receive those plans and read them, I notice something funny. When I ask a question about a section, my friends have no answers . They have to go back to the AI to get an answer. Why don't they have an answer? Because they are reading it for the first time with me. Basically, because the plan is long and elaborate, who has time to read it? The satisfaction is in the format and complexity, not in the execution of the plan. They had an idea, ChatGPT improved it, then it built a plan and solution for the problem. So their idea now has a solution, and the solution must be correct because AI came up with it. The problem is solved, we can file it in a cabinet. Executing it was never the issue. I'm sure there will be a psychological term for this. A term for getting a psychological reward from watching AI come up with a plan of execution for your ideas. This isn't specific to OpenAI's ChatGPT, it's a catch-all for all generative AI in the current market. Even when I'm doing research for a blog post, I'm often caught in the "Would you like me to expand further on this?" questions that can easily lure you into a rabbit hole. I guess AI providers are learning from social media. In social media, the goal isn't to socialize with friends and family anymore. Instead, they are trying to keep you engaged for as long as possible, to expose you to the maximum number of advertisements. With AI, the goal isn't to impart you with knowledge. Instead it's to give you the satisfaction of appearing knowledgeable by keeping you engaged with an AI while they expose you to ads and spend your tokens.

ai AI business Business
0 views
iDiallo 1 months ago

What Do You Charge For?

I've written about my journey to learn how to charge a fair price for building a website before. But even after landing on a strategy, there is still a question that remains unanswered. What should I charge for? Are you charging the price for the product itself? As in, the very cost for building a website? Or are you charging enough to make a living? This question applies to any field, whether you are a consultant, a mechanic, or a private chauffeur. I once worked with a company that built websites for non-profits. Their price tag? $35,000 for a standard WordPress site. Lucky for me, I got a first-hand view of their price breakdown because they were trying to expand their reach to smaller customers. They needed to figure out how to lower the price, so they invited me to the meeting. Every single person in the room was involved in building the website. The standard time frame to complete it was 6 weeks. So, the manager named each person, their title and how much time they spend on the project. There were the designers, the copy writers, the consultants that gathered the information. There were the sales people who started the process, the 2 developers that included me. Everyone at the table was indispensable. Then he gave a ball park estimate of salaries using glassdoor standards, and the price jumped to 35k. It was completely fair. "What if we have Ibrahim as the sole developer on this tier?" the director asked. "And we use only one designer, and we can reuse copy." The manager crunched the numbers and we were still going to charge 25k. "What if I don't get involved at all in this tier?" the manager removed the director's name from the list. He contributed only a couple of hours of work, yet the number went down to 22k. I originally thought $35k was an astronomical amount for a website, but their breakdown showed it didn't even include profit. The salary costs alone ate up the budget. The actual profit for the company came later, from managing the marketing campaign. This is Cost-Plus pricing. You add up what it costs to make the thing, and that becomes the price. It feels logical, but it relies entirely on your costs, not the value you provide. But then, there is another way. The market-based pricing. Take a car, for example. A vehicle costs $35k because that is what the market is willing to pay for that specific make and model. The materials and labor to build the car might be significantly cheaper, or on occasion even more expensive (Rivian) than the sticker price. The price is dictated by the buyer's perceived value, not just the manufacturer's receipt. This method became clearer to me after I started consulting. When I would get a new client, I initially tried to price based on the old model of calculating what I thought my time was worth from a salaried perspective. I later found that the recruiting company I worked with was charging clients $78 per hour for my services, while paying me $40. The market (or the recruiter's markup) was valuing my time at nearly double what I was charging myself. You know the mechanic is gonna charge you extra for that flat Then, there is the wild card method. I've been the unlucky guy who finds himself out of town with a flat tire. I stop at the first tire shop I can find, and the worker doesn't size up my car; he sizes me up. He decides how much to charge based on how desperate I look. In those misadventures, the price has ranged anywhere from $20 to $150. I'm usually in no position to argue when I'm stranded on the side of the road. But how do they decide on those numbers? Are they making a profit? Or are they just charging whatever they think fills their quota for the day? This is opportunistic pricing, highly effective for a quick buck, but I don't think you can build trust like that. All these methods for charging have their pros and cons. My goal isn't to tell you which number to pick, but to encourage you to decide how you pick that number. My advice, in the simplest terms, is this: Be consistent. Once you choose a method, it becomes your standard. Do not deviate. If you charge based on value today, but switch to charging based on your mood tomorrow, your clients will never trust your pricing. They will always wonder if they are getting the "real" price or just the price you felt like charging that morning. They will start looking for other consultants. Pick the method that works for you, stick to it, and let your clients know exactly where they stand. Personally, I apply a value based pricing with my clients, where the cost is tied to their specific needs and the time required to meet them. It's a method that requires trust and communication, but it can be the most fair and profitable for both parties when applied consistently. When they end up with an obscene bill , at the very least they are prepared.

business Business career Career
0 views
iDiallo 1 months ago

How to Come Up With Great Ideas

There's a story about an art teacher who divides a class into two groups. The first group is given one task. Design a single, perfect pot. The second group has a different instruction entirely. Make as many pots as you can before time is up. The first group measures, plans, and deliberates. They sketch ratios, debate proportions, and handle the clay with care. They have one shot, so they treat it like one. The second group just makes pots. Terrible ones. pots that collapse on themselves, crack at the base, and lean sideways. They don't stop to mourn any of them, they just start the next. When time expires, the results are revealed. The first group has a pot... technically. But it wobbles. Before the session is over, it breaks. The second group's first pot is a disaster. But their second is better. Their third, better still. By the time they've burned through a dozen attempts, they've internalized something the first group never had the chance to learn. What doesn't work. Their final pot is flawless The second group won not because they were more talented, but because they were given the opportunity to experiment and gain experience. When it comes to writing, it's tempting to believe you need the entire story mapped out before you begin. That you need to fully understand the premise, complete the research, and know the ending before the first sentence. That's never been true for me. When I start writing, I often don't know what it's going to be until the words appear on the page. The research doesn't precede the writing. It follows it. I remember watching the Pixar documentary about Finding Nemo. They produced hundreds of story sketches and character drawings that never made it into the film. The director admitted that a lot of those ideas were pretty terrible. But without those sketches, they wouldn't have arrived at the final story. They learned from the volume of attempts. And we got to watch the final high quality result. I've been following what I call the 100-times rule . For any new skill, or anything new really, I give myself permission to do it 100 times before judging the results. The goal is simple. I want to narrow the gap between idea and execution. When I was learning to program, I'd open a blank JavaScript file and just start writing. Half the time, I'd finish a session with something unrelated to what I started. A half-baked startup idea buried in the comments, or a function that suggested an entirely new project. The work generated the ideas, not the other way around. When I decided to write regularly, I had about a dozen ideas ready to go. I dreaded the moment I'd exhaust them. But by the time I published the twelfth post, I had several dozen more. They didn't come from some secret source of inspiration. They came from momentum. Writing regularly has trained my mind to notice things worth writing down. Conversations, observations, small frustrations, fleeting questions. The ideas were always there. I just hadn't built the habit of catching them. This is the part most people get backwards. They wait for a great idea before they begin. But great ideas are rarely the starting point. They're the result of effort. You don't think your way to good work. You train yourself to good thinking by using repetition. When I have an idea now, I don't wait for the right moment. I write it down immediately in my phone, in a note, sometimes directly on my blog before I fully understand it. Publishing something unpolished is uncomfortable. But an unpolished idea that's out in the world can be refined, responded to, and built upon. A perfect idea that lives only in your head cannot. In fact, I've forgotten so many great ideas! Since the beginning of last year, I've written at least 230 articles. When I run low on new ideas, I have hundreds of old posts I can return to, deepen, and remake into something more considered. The volume created the options. If there is any secret to coming up with great ideas it's this: Start before you're ready. The first group in that classroom failed not because they were less capable, but because they optimized for perfection at the expense of experience. Every moment they spent planning was a moment they weren't learning what the clay actually does in your hands. If you're waiting for the perfect idea, the right time, or enough certainty before you begin then you are the first group. You have one pot and you're protecting it. Make more pots.

writing Writing career Career javascript JavaScript
4 views
iDiallo 1 months ago

Advice from a millionaire

#storytime "Is this seat taken?" A man dressed in a black suit and a coffee in hand asked. He was already halfway into the chair when he said it. I was at the adjacent table when I heard it. He wasn't asking me. He was asking the woman who looked up, one hand holding a paper cup, the other trying to keep a small boy from sliding off his seat. A second child sat beside her, quietly peeling the label off a juice bottle. "Michael, no!" she yelled at the kid. But that didn't deter him, he was sitting beside her, sipping on his latte. I noticed him because he didn't belong to the table. He had given himself permission to be part of this story. At first I could only hear fragments of the conversation carried between the hiss of the espresso machine and the scrape of the chairs. "…people always ask me…" "…not about luck…" "…mindset is everything…" He spoke with the rhythm of someone used to being listened to. Not pausing for responses, just enough space to suggest one might exist. The woman nodded, when it seemed appropriate. Not because she agreed, I think, but because her attention kept breaking apart. The younger child had dropped something. The older one was tugging at her shirt asking a question that went unanswered. He leaned forward, elbows on the table, lowering his voice as if sharing something confidential. I leaned in. "You have to recognize opportunity," he said. I caught that part clearly. "Most people don't. They're not trained to see it." The woman murmured something, agreement, maybe. Or just acknowledgement. She clearly wanted to listen, to hear him. But her eyes drifted to the door when it opened. Then to the counter when a name was called that wasn't hers. He didn't seem to notice. "People often ask me how I made my first million dollars, like what the turning point was?" he continued. "And I tell them, it's never just one moment. It's discipline. Consistency. Character." One of the kids tugged at her sleeve. She bent down, whispered something, brushed hair out of the child's face. The man waited, but not really. More like he paused until the interruption stopped existing. "Early in my career," he said, picking up exactly where he left off, "I joined a small company. Nobody had heard of it." He smiled, like this was the part that mattered most. "But I saw something." The phrase hung there. I had the sense he liked the way it sounded. "They always ask me, 'How did you know?'" he said, shaking his head lightly. "And the truth is, I had prepared for this every single day of my life. So when the moment comes, you just know." The older child had started tapping the table with a plastic lid. A soft, repetitive sound. The woman placed her hand over it gently, stopping the rhythm without looking away from the man. He kept going. "We were a small team. Took risks. Worked hard. No guarantees." He gestured vaguely, as if summing up effort itself. "That's what people don't understand." The woman nodded again, looking at the counter if her name was ever going to be called. "They gave us stock," he added. "Didn't mean much back then." He said it casually, like it wasn't the point. Like it was just part of the scenery. "And then we got acquired." He leaned back slightly, watching her reaction. I don't think she gave him one. "A bigger company came in," he said. "That's what happens when you build something valuable." Behind the counter, milk steamed loudly. Someone laughed. A chair fell over and was quickly set back upright. "At that point," he continued, "those shares… well." He made a small lifting motion with his hand. The woman followed the movement with her eyes, just for a second. "That's the strategy," he said. "Recognize opportunity. Take risks. Build character." He delivered it like a conclusion. Something that could be written down. The younger child had climbed halfway out of the chair now. She pulled them back gently, whispering again. This time more urgently. He checked his watch. Then, as if remembering he was not alone in the conversation, he asked, "So what do you do?" The question landed awkwardly, like it had been taken from a different script. She hesitated. This whole time she had been made to listen. Now her answer was needed. "I'm… figuring things out right now," she said. It was the kind of answer that usually ends a line of questioning. He nodded, but it didn't slow him down. "That's good," he said. "You have to stay open. That's how opportunities find you." One of the kids started crying. Not loudly, but enough. She stood halfway, then sat back down, unsure which problem to solve first. He smiled, patient in a way that suggested he believed he was being generous with his time. "Anyway," he said, standing up and adjusting his jacket, "that's how I did it." He placed a business card on the table. It slid slightly, stopping near the peeled labels. "Come find me when you're ready to talk about becoming a millionaire." She nodded, because there was nothing else to do. He left without looking back. But he looked in my direction and noticed me. He stopped. Walked over, and shook my hand with both of his. "I've read everything you've written," he said. He stood there a moment longer, as if hoping I might say something he could write down. I didn't. He left. I went to the counter and asked for hot water in a cup. The barista made it available without question. From my coat pocket I produced a small paper envelope, mint and garlic, blended to a ratio I had refined over many years. I placed it in the cup and let it steep. I never leave the house without it. It is the first thing I take in the morning and the last thing I take at night. There is a clarity it produces that I have not found elsewhere. I walked to the woman's table. She looked up. I sat down, and moved her drink to one side. "This will serve you better," I said, and placed the cup in front of her. She looked at it. One of the children leaned over to smell it and made a face. I didn't acknowledge this. "The mind," I said, "cannot find opportunity in a state of agitation. I learned this early." She wrapped both hands around the cup, the way people do when they don't know what else to do with them. I placed my card on the table. It was a solid thing, matte black with beveled edges. It covered the millionaire's card entirely. "Come find me," I said, "when you're ready." I didn't say for what. I didn't need to. She could tell I was a billionaire. A barista in a coffee shop told me this story. Not verbatim, but it was funny. Two "rich" guys trying to give advice to a woman and her two kids who live in a van. They feel like they had done her a great service. One offered useless advice, the other offered hot smelly water. Neither of the men helped her. I thought it would make a perfect LinkedIn story.

business Business career Career
0 views