all posts tagged 'programming'

Writing Javascript without a build system


šŸ”— a linked post to jvns.ca » — originally shared here on

I make a lot of small simple websites, I have approximately 0 maintenance energy for any of them, and I change them very infrequently.

My goal is that if I have a site that I made 3 or 5 years ago, Iā€™d like to be able to, in 20 minutes:

  • get the source from github on a new computer
  • make some changes
  • put it on the internet

But my experience with build systems (not just Javascript build systems!), is that if you have a 5-year-old site, often itā€™s a huge pain to get the site built again.

I have websites that I made in middle school that Iā€™m able to get up and running in roughly as much time as it takes to find the old folders.

I also have websites that I am unable to run on my new laptop because the dependencies are too out of date and now supported on my new architecture.

Continue to the full article


What Is React.js?


šŸ”— a linked post to briefs.video » — originally shared here on

In summary:

  • Facebook is a [redacted] company with a terrible web interface.
  • React is a technology created at Facebook to administer its interface.
  • React enables you to build web applications and their interfaces the way Facebook does.
  • I am not calling Facebook "Meta"
  • JavaScript-first interfaces built on ecosystems like Reactā€™s are cumbersome and under-performing.
  • React prevails because its evangelical proponents and apologists have convinced developers that Facebookā€™s success can be attributed to technological quality and not aggressive capitalism.

Over the past fifteen years, I feel like Iā€™ve had a pretty good track record of knowing which technologies to pay attention to and which technologies to confidently let pass by me.

When React first dropped, I thought the setup process seemed so onerous and filled with so many dependencies that I slowly backed away and haven't really needed to look back.

It would be irresponsible of me to have zero experience in React, so of course I've inherited projects that others have started on top of it. But every time I jump into a React project, I feel like Iā€™m Homer jumping into his unchlorinated pool.1


  1. I mean, this is how I feel every time I jump into a Facebook-owned property these days. 

Continue to the full article


Five Behaviours to Become an Effective Staff-Plus Engineer


šŸ”— a linked post to infoq.com » — originally shared here on

This talk helped me articulate a few key arguments that I can use to counter myself when in the throes of impostor syndrome-related attacks from my inner monologue.

Basically, a ā€œstaff-plus engineerā€ is anyone in a technical role that is higher than a senior engineer. These are sometimes referred to as principal engineers, staff engineers, etc.

The big difference between staff-plus and individual contributor path is that an IC role is one you go down when you truly want to contribute as an individual, often acquiring such an expertise in a specific domain that you just do your thing alone.

A staff-plus role requires collaboration, often leading teams, but always being the lynchpin which helps be the voice of technical leadership across multiple teams.

The responsibilities of a staff-plus role include (probably) writing and (definitely) reviewing code, providing technical direction, mentoring and sponsoring other engineers, providing engineering context to non-technical people, and being involved in strategic projects which arenā€™t shiny but are critical to the success of an organization.

I think I came across this talk at a timely point in my career. I have been tasked with doing staff-plus engineering work ever since starting my first company, and itā€™s honestly the stuff I love the most.

Iā€™m not a developer who loves to write code. I love writing code because it results in a tool that makes someoneā€™s life easier. What brings me joy is in doing the discovery work needed to clearly articulate the problem and charting a course thatā€™ll lead us to a solution.

Continue to the full article


Everybody's Free (To Write Websites)


šŸ”— a linked post to sarajoy.dev » — originally shared here on

Enbies and gentlefolk of the class of ā€˜24:

Write websites.

If I could offer you only one tip for the future, coding would be it. The long term benefits of coding websites remains unproved by scientists, however the rest of my advice has a basis in the joy of the indie web communityā€™s experiences.

I love the reference to Wear Sunscreen, one of the great commencement speeches.

There is amazing advice and inspiration for building websites in here. It also reminded me of POSSE, meaning ā€œPublish (on your) Own Site, Syndicate Elsewhere.ā€

Continue to the full article


Comfortable with the struggle


šŸ”— a linked post to rachsmith.com » — originally shared here on

Iā€™ve known developers whoā€™ve put up with the struggle with the expectation that one day it will go away: one day theyā€™ll be an expert and never have to struggle again. This day never arrives, and so they bail out of the field.

Unfortunately, I donā€™t think the struggle ever goes away. Iā€™ve been doing this professionally for 14 years now and I still have to deal with the struggle almost every work day.

If you can be comfortable with the struggle and build up your tolerance for it. If youā€™re able to sit in that moment and be okay without drama or a total crisis of confidence, Iā€™m fairly sure youā€™re going to do just great.

The Struggle comes in multiple shapes and sizes too. Here is a short list of my experiences with The Struggle from this week alone:

  • Impostor syndrome
  • Anxiety about breaking a physical connector
  • Frustration with unclear objectives
  • Being overwhelmed by unfamiliar technologies
  • Debugging something and being unable to find an answer

After 12 years of professionally dealing with The Struggle, Iā€™m still able to handle many aspects of it, but my tolerance is quickly diminishing.

Dealing with The Struggle is much easier when you feel like thereā€™s a reward for you at the end of it. Right now, Iā€™m trying to restore my old iPod fifth gen with an SD card, and no matter what I do, I cannot get it to work right.

Iā€™ve been all over forums, digging into the sixth and seventh pages of search results, desperately looking for clues as to why Iā€™m not getting it to restore.

But I can picture myself playing that brick breaking game soon, and that first game is gonna be so much fun after all of this work.

Continue to the full article


Choose Boring Technology


šŸ”— a linked post to mcfunley.com » — originally shared here on

I saw this article referenced while reading Bill Millā€™s recap of relaunching a website, which in and of itself is a delightful read for those of us who nerd out on large-scale system architectures.

I am almost certain Iā€™ve read Danā€™s piece on boring code before, but I wanted to share it here because it serves as a great reference for those of us who are sick of making bad tech stack decisions for bad reasons.

In particular, the ending here sums up my experience consulting with many different tech teams:

Polyglot programming is sold with the promise that letting developers choose their own tools with complete freedom will make them more effective at solving problems. This is a naive definition of the problems at best, and motivated reasoning at worst. The weight of day-to-day operational toil this creates crushes you to death.

Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.

The teams which move the fastest are the ones who are aligned on a vision for what is being built.

Often, these teams hold a ā€œstrong opinions, loosely heldā€ mentality where they decide what tools theyā€™ll use, and theyā€™ll use them until they no longer solve the problem at hand.

Put another way: in a business context, experimenting with your tooling is a huge organizational expense that rarely yields a worthwhile return on investment.

Your focus should be on what you are building rather than how youā€™re building it.

Continue to the full article


Security at Startup


šŸ”— a linked post to vadimkravcenko.com » — originally shared here on

In my opinion, security is one of the most forgotten aspects of software engineering. It rarely gets focused on until itā€™s too late. Even though at least one incident lands on HackerNews every week where some data gets leaked or someone gets hacked ā€” people still think, ā€œNobody cares about my little startup.ā€ You might think you're too small to be noticed by the big, evil hackers. Wrong. Size doesn't matter. You're always a target; thereā€™s always data to leak and ways to exploit your business.

This is a great primer for the security-related items you need to consider when youā€™re building software.

Some takeaways:

First, any human-built product is going to be insecure. Nothing is 100% secure, ever. The best you can do is make the bad guys earn it by making it difficult to break into.

Second, your biggest vulnerabilities are almost always human. You can build Fort Knox, but if Iā€™m able to trick your guard into opening the door for me, then whatā€™s the point?

Third, Iā€™m grateful for frameworks like Ruby on Rails which handle a good chunk of the authorā€™s ā€œstep 0ā€ items out of the box. Picking the right tool (and keeping that tool sharpened) is the best first step.

Fourth, thereā€™s never a moment with software when you can dust your hands and say, ā€œope, weā€™re done!ā€

Security is especially an area in which you canā€™t sit still. If you build an app and let it sit for a decade without any updates, I can almost guarantee you that thereā€™ll be a vulnerability in one of your dependencies which I could exploit to take over your system.

Finally, if you reach a certain size of organization, you need someone thinking about this stuff full time and orchestrating all the pieces needed to keep a secure system.

Continue to the full article


Home-Cooked Software and Barefoot Developers


šŸ”— a linked post to maggieappleton.com » — originally shared here on

I have this dream for barefoot developers that is like the barefoot doctor.

These people are deeply embedded in their communities, so they understand the needs and problems of the people around them.

So they are perfectly placed to solve local problems.

If given access to the right training and tools, they could provide the equivalent of basic healthcare, but instead, itā€™s basic software care.

And they could become an unofficial, distributed, emergent public service.

They could build software solutions that no industrial software company would buildā€”because thereā€™s not enough market value in doing it, and they donā€™t understand the problem space well enough.

And these people are the ones for whom our new language model capabilities get very interesting.

Do yourself a favor and read this entire talk. Maggie articulated the general feeling I have felt around the promise of LLMs within the confines of a concise, inspiring talk.

A friend approached me a few months back and asked me to help him build an app to facilitate a game he likes to play with his friends in real life.

I told him that a good first step would be to experiment first with facilitating the game using good olā€™ fashioned paper, and use the lessons learned from that experience to eventually build an app.

A few weeks later, he came to me with a fully baked version of the app in a prototyping tool called AppSheet.

I was stunned at how much he was able to get done without any professional development support.

Heā€™s a prime example of a barefoot developer. I donā€™t think he has any interest in crossing the ā€œcommand line wall,ā€ but as these tools get more capable, itā€™ll enable him and scores of others to build software thatā€™ll solve their problems for them.

Helping more ā€œnormal peopleā€ to become barefoot developers is a cause Iā€™d love to be part of.

Continue to the full article


ChatGPT is really bad at generating code to interact with GPT-4

originally shared here on

Lately, I've been working on several projects which interface with the OpenAI APIs.

Since this is 2024 and I'm far too lazy to open the official API documentation and write code myself, my first step in generating code is to ask the 4o model of ChatGPT something like this:

Write a Python script which uses the latest OpenAI APIs. I'd like the function to accept a custom prompt and a custom top-k value. It should return the prompt's response.

It returns something like this:

import openai

def generate_text(prompt, top_k=5):
    # Define your OpenAI API key here
    openai.api_key = 'your-api-key'

    # Define parameters for the completion
    completion = openai.Completion.create(
        engine="text-davinci-003",
        prompt=prompt,
        max_tokens=100,
        top_k=top_k,
        n=1,
        stop=None
    )

    # Return the generated text
    return completion.choices[0].text.strip()

# Example usage
prompt = "Once upon a time"
top_k = 10
generated_text = generate_text(prompt, top_k)
print("Generated Text:", generated_text)

Which looks super great, right?

Except when you go to run it in a terminal, you get this:

openai.lib._old_api.APIRemovedInV1: 

You tried to access openai.Completion, but this is no longer supported in openai>=1.0.0 - see the README at https://github.com/openai/openai-python for the API.

You can run `openai migrate` to automatically upgrade your codebase to use the 1.0.0 interface. 

Alternatively, you can pin your installation to the old version, e.g. `pip install openai==0.28`

A detailed migration guide is available here: https://github.com/openai/openai-python/discussions/742

If you paste that error into the chat, it'll respond with this:

It seems like there has been a major update in the OpenAI Python library since I last checked. Let me update the script to use the latest version of the library:

And then it spits this out:

import openai

def generate_text(prompt, top_k=5):
    # Define your OpenAI API key here
    openai.api_key = 'your-api-key'

    # Define parameters for the completion
    response = openai.Completion.create(
        engine="davinci-codex",
        prompt=prompt,
        max_tokens=100,
        top_k=top_k,
        n=1
    )

    # Return the generated text
    return response.choices[0].text.strip()

# Example usage
prompt = "Once upon a time"
top_k = 10
generated_text = generate_text(prompt, top_k)
print("Generated Text:", generated_text)

Notice how it still uses the openai.Completion method!

I've tried prompting it with something like:

You're still using the openai.Completion method. Reference the official up to date API documentation to get the latest call that replaces the openai.Completion method.

And it responds with:

Apologies for that oversight. Let me update the script to use the latest API method based on the official documentation:

And here's the code it generates:

import openai

def generate_text(prompt, top_k=5):
    # Define your OpenAI API key here
    openai.api_key = 'your-api-key'

    # Define parameters for the completion
    response = openai.Completion.create(
        engine="davinci-codex",
        prompt=prompt,
        max_tokens=100,
        top_k=top_k,
        n=1,
        temperature=0.7,
        stop=None
    )

    # Return the generated text
    return response.choices[0].text.strip()

# Example usage
prompt = "Once upon a time"
top_k = 10
generated_text = generate_text(prompt, top_k)
print("Generated Text:", generated_text)

Which, again, still uses the openai.Completion method!

I've noticed this sort of "oops, I screwed up, here's the exact same thing I just outputted" behavior appear more frequently when I use the new GPT-4o model.

If I use GPT-4 and I'm using my ChatGPT Plus subscription, I will still run into the issue where its first response references the deprecated method, but if I inform it of its mistake and provide a link to the official documentation, it'll access the web and try to offer something different. (It still generates unusable code lol but it's at least trying to do something different!)

When it comes to Python and Rails code, I'm seeing that the GPT-4o model is not as good at code generation as the previous GPT-4 model.

It feels like the model is always in a rush to generate something rather than taking its time and getting it correct.

It also seems to be biased toward relying on its training for supplying an answer rather than taking a peek at the internet for a better answer, even when you specifically tell it not to do that.

In many cases, this speed/accuracy tradeoff makes sense. But when it comes to code generation (and specifically when it tries to generate code to use their own APIs), I wish it took its time to reason why the code it wrote doesn't work.


Rapid skill acquisition and adapting to new career opportunities


šŸ”— a linked post to justin.searls.co » — originally shared here on

Joelā€™s original post is an excellent read, but I really enjoyed Justinā€™s statement at the end of his linked post:

One last note: showing up to a client following a weekend-long crash course in a particular technology doesn't make you a fraud. Nearly twenty years in consulting has taught me that the people most worried about misrepresenting themselves and their abilities are the people who have the least reason to worry. The fact they care so much almost always means they'll put in the work when they need to. The real frauds, meanwhile, don't worry at all. And while Joel was holed up in a Starbucks for 72 hours, I'm sure they were having a delightful and relaxing weekend. And Joel's much richer for it, as he's gotten four careers' worth of experience by repeatedly diving into new industries, organizations, and technologies, whereas the real imposters only learned how to talk a good game as they skated through life without ever stretching themselves.

Iā€™ve seen first hand the nerve some developers bring to a first meeting, only to dim gradually over time.

I continue to struggle sometimes with confidence in what I do, but my entire career so far has been non-stop learning.

Every project is an opportunity to learn a new framework, a new project management style, a new business problem.

Itā€™s a hard characteristic to put on a resume, but the ability to pick up new systems quickly is definitely one of my core strengths.

Continue to the full article