You can download the GPT model and interrogate local files using Python without having to send any data to the cloud.

PrivateGPT is a python script to interrogate local files using GPT4ALL, an open source large language model. It is pretty straight forward to set up:

• Clone the repo
• Download the LLM – about 10GB – and place it in a new folder called `models`.
• Place the documents you want to interrogate into the `source_documents` folder – by default, there’s a text of the last US state of the union in there.
• Run the `ingest.py` script – this can a long time. On this MacBook M1 it was 2 minutes though
• Run the `privateGPT.py` script and you get a prompt in your Terminal:

I asked it what the US president has to say about the situation in the Ukraine and it gave me a synopsis and where in the document the information is from.

Neat!

As part of one of the job applications I have going I was invited to do a frontend expertise exercise. The role I am applying for is head of frontend for a company. Whilst I found it odd to have to go through this, with my track record being highly visible, I thought, why not? After all it feels sensible to make everyone do the same work to get a job, should you want to compare directly.

Incidentally, this was a big no-no in Mozilla – we never compared applicants, we just measured them on their own results.

I was already confused about the format of the exercise. I had to go to a third party web site and start the assessment. I had all in all 3 hours to finish it. The first 25 minutes were a multiple choice survey that would cover the basics of web development, CSS and accessibility and the rest would be a JavaScript exercise. I already found this painfully askew and maybe a damning view of what web development is these days.

The frontend knowledge part

So I started and got a few multiple choice questions that should validate my chops as a web developer. The questions were:

• Which REST method to use for what action
• What a good REST URL structure would be to access an element of a collection by ID.
• Why JavaScript is a great language offering me four choices of its structure (event loop, object notation…)
• Why Python is a great language for the web
• What the benefits of Kubernetes are
• Defining what Docker is
• What accessibility should be part of (design, supporting screen readers, testing, all of the above)
• How to place a DIV to the left of an element (with float being the only option, no flexbox or grid)

This was nothing short of a mess. This was a frontend role. Why would Kubernetes and Docker be in there unless I’d also be responsible for the developer environment and setup. And the frontend related questions were borderline ridiculous. Sure, finding out that accessibility should be part of every step of the process is good, but the question was so vague and there were no details asked what it would need to make a product accessible. What are the main stumbling blocks? What are things we can not do easily and what would be a workaround to offer as an alternative. There was no question about HTML, structure of documents, semantics or interactivity of elements. There was nothing about performance, nothing about security, nothing about the DOM, nothing about CSS other than a hack we should not be using any longer.

The coding part – should I build something for the web?

OK, maybe the JavaScript test would make up for it. Maybe build an app, create an interface and show what I know about that and how to write code that my team later on would find easy to understand and maintain.

The product asked me to either use an in-browser IDE for the task (Monaco, it seems) or clone a GitHub repo and use my own setup. Of course, I chose the latter. It was a sample app with tests already set up and I needed to install it with NPM and use Node to test my solution. No interface at all. Nothing. Just a test suite and a task to complete. The task was to implement a calculator with an alternative syntax to the usual infix notation. I had to write a function that would take a string and return a number. The string would be a mathematical expression in prefix notation. So instead of 1 + 2 it would be + 1 2.

I was a bit confused. I have never seen this notation before and I have been a web developer for 25 years. I have seen a lot of things, but this was new to me. I had to look it up and found that it is a notation that is used in Lisp and other languages. I was not sure why I would need to know this, but I thought, OK, let’s do this. I have 2 hours left, so I can do this.

In the end, I wrote a 20 line JavaScript in 10 minutes and was done. A few gotchas were reversing the array of tokens and flip the order of operands when doing subtractions. How this relates in any way to a frontend role? No clue.

I do like the idea of giving applicants a GitHub repo to clone, set up the dependencies and work on the script until all tests are green. This should be a basic workflow we all are familiar with.

Hiring amazing frontend developers by giving them vague frontend task

The best frontend developers I ever worked with were in Yahoo back in 2006. The reason was partly because we hired people we already knew from mailing lists, conferences, people who wrote about frontend tasks and were keen to share their knowledge.

Another big part of it was the interview process and specifically how we tested people’s frontend skills. What we did was give them a design and a specification how the interactions in that design would work. There was a collapsible menu and a carousel. There was a form that we asked to add client side validation. The design had a few accessibility problems and some subtle inconsistencies.

Applicants could to this in their own time and send us the result (as a zip, most of the time – I had mine hosted on my server in my interview). We then invited them to come to the office and talk us through their solution.

We would ask applicants to:

• Talk us through their solution and why they chose it.
• Show us how they would debug a problem and how they would find out what the problem is.
• Show us how they would test their solution and how they would make sure it works in all browsers.
• Criticise the design. What would they change and why?

The crucial part was not the solution itself. The crucial part was how they explained their solution and how they would approach a problem. We were not looking for the perfect solution, we were looking for people who would be able to work in a team, who would be able to explain their work and who would be able to find out what the problem is and how to fix it.

I remember vividly one of the applicants not knowing that I was part of the interview process and them having used a script from my JavaScript book to solve the solution. I asked them to explain the code and they did. I asked them what they could think of to improve it and they did. The code was open source, so there’s no harm done and I did end up hiring that person.

That, to me, is a sensible test to see how someone approaches web development. What I just filled out is probably a good test to see if someone is a good developer, but it is not a good test to see if someone is a good frontend developer. Give people things to fix. Give people a product that has problems and ask them to improve them or explain why they are issues. Frontend is about building things people use. There is no single solution, there are many ways to solve the same problem. The crucial part is to understand the problem and to find a solution that works for the people who use it. And to understand the environment web products are executed in (browsers) and the technologies that power the interfaces of the web: HTML, CSS and JavaScript – not Kubernetes and Docker.

Hooray, Goto conferences just released the video of my talk on Developer Tools.

If you want to play along with the examples, they are available on GitHub.

First of all, congratulations. You managed to kick off the next step of computer and human interaction evolution. Of course we’re in the middle of a hype, but there is so much good in AI generated content and conversational interfaces, it’s pretty safe to say all things “computer” will have some part of this included going forward.

You have an issue though: relevance. Or, as some call it, hallucinations. Systems fed with lots of data that wasn’t quite quality controlled that manage to make even erroneous data sound like the best thing since sliced bread could turn out to be disastrous in the long run. Just because something sounds clever, doesn’t make it good.

Here’s the bad news: the wisdom of the masses will not save you. As someone who worked on products with millions of users and highly visible interfaces like browsers I can tell with great confidence that people will not downvote and report wrong results.

The idea of increasing the weight of results that were the end of a conversation is also flawed. It’s like asking your obviously miffed partner what’s wrong and they answer “nothing”. This is not the end of that conversation.

Dissatisfied users do not put an extra effort in to downvote the wrong result – they just leave as they feel that they already wasted enough time with your product.

How to make that better? Well, one way is to give your systems context and limit it to that one. GitHub Copilot for docs is a great example of that.

The other, and here is where I come in with my pitch, is to consider editors, writers and tech experts to flood your product with great solutions, downvote obviously wrong ones and annotate others to explain that whilst this is a solution, it may come with a caveat.

The great opportunity you have right now is that the market is saturated with laid off people who have some time on their hand. These are experts in certain fields: programmers, designers, product managers and many others. Ironically, you will also find a lot of technical writers to work with right now as they have been laid off as part of an overreaction to your success. Who needs authors when the machine can generate lots of text for free (or pennies in traffic)?

Of course, creating a community of experts to talk to your machines takes time and effort. Guess what? A lot of community managers were also laid off when companies closed their tech communities.

As an expert editor or “GPTeacher” I could get in addition to the upvote, downvote and copy icon also one that allows me to edit the response. This would go into a review process with two others and then back into the system.

As a developer known to you as a “GPTeacher” I could write code examples on GitHub and tag them with a special tag #gptfodder (or, whatever), and again, after a peer review with others it’ll get more weight to be shown in a higher frequency in conversations people have with your systems.

I know, all of this feels a bit old school and Wikipedia-ish. But, it worked in the past and it scales much better than hiring a lot of people in outsourcing markets to clean up things that are obviously wrong.

We are at a crucial point here. Some governments already work on laws to block your systems as there is no attribution or licence information in your results. It would be a shame if we let machines educate people the wrong way because we were not interested in giving the system human supervision when it was needed.

Want to know more? Let’s start a conversation and build a community of enthusiastic experts that are OK to teach the machine to do better rather than hoping people will be able to see the flaws in the conveniently offered, clever sounding solution.

I am currently looking for a new job. One thing that keeps happening is that people get my CV, are impressed but then ask me that I seem to be focused on the front end a lot and what my experiences with backend and full stack development are. It seems to me that we’ve come full circle back to when I started as a web developer and had to sell and explain the notion of a front end expert as a real, full-time job, 21 years ago:

Here’s the deal: a frontend developer isn’t a mediocre coder that only dabbles in “easy” languages like HTML, CSS and JavaScript. A frontend developer is someone who made a conscious choice to build interfaces for the unknown with a laser sharp focus on the end user’s experience.

The web isn’t just another compilation target. It’s a platform that allows the user full control over the look and feel. It’s also the only platform resilient enough to weather any change you throw at it. The web works on desktop, android and iOS. And it can do that with one codebase. If you have dedicated developers who know what they are doing and don’t just expect to find a plugin or extension that will magically make your product accessible to all and perform well.

Here’s the not so dirty secret: no matter what platform you choose, what language you write your code in or what framework or library you use – the final thing that arrives on your web users devices is HTML, CSS and JavaScript.

Each (with HTML to a small degree) can cause performance problems, cross-browser functionality issues and become a barrier for users on sub-par connections and platforms or with different abilities. Slow performance is known to lose you end users and being inaccessible is a legal and compliance issue that can get you sued.

I’ve worked on the biggest web sites on this web (yahoo.com, bing, Microsoft…) and on the Firefox and Microsoft Edge (Chromium) browser. Browser makers want one thing: not being blamed for being slow or showing things “wrong”. So we work with lots of internal and external partners to see why their products are misbehaving. This could be extension providers, framework creators or development teams. In these “performance clubs” both in Mozilla and Microsoft we kept running into the same issue: web products with tons of senseless HTML, mostly unused CSS and an absolute avalanche of JavaScript sent to the end users with no benefit to them. All the benefits were for the convenience of the developers and the flexibility to build whatever with a framework that promised optimised output.

The move to full stack development caused us to build a bloated web that loses you customers and costs you a lot of traffic that simply isn’t necessary.

There is of course another reason why our web products don’t deliver: componentisation without big picture planning.

Web products these days aren’t build as documents, sites or even includes. They are built as independent components, each flexible enough to be applicable in many different contexts. That’s grand, until people assemble them nilly-willy and as many as they want to. At times we found 20 different, highly customisable button components that did the same thing.

Here’s where a frontend developer would smell that something is amiss immediately and could trace the waste.

Frontend developers are:

• Browser performance experts
• Cross platform development experts
• Accessibility experts
• Compliance knowledgeable
• Design and Test department connected
• Fiercely dedicated to the end user

We truly are the shape shifters of the market. So to say that someone who is “just” a frontend developer isn’t flexible enough means first and foremost that most people still don’t know all the things this job requires.

The argument that CSS and client side JavaScript isn’t real coding is nonsense, too. It’s especially ironic that people who claim that also don’t want to touch CSS as it is “too hard and strange”. CSS isn’t about colours and padding any more, with grid, subgrid and flexbox it’s a fully fledged layout system. And it does animation and responsive rendering. With media and container queries you have amazing flexibility and with cascade layers you even have control over how browsers should render the current design.

It is your choice. You can hire frontend developers to build your product, or make it happen somehow and later on hire performance and accessibility consultants to fix what doesn’t work properly. Bear in mind though that the further down the production you are, the harder it will get to optimise and fix a product as you will also clash with new feature work.

When people ask me why I am “just doing frontend”, I can happily explain these things and proclaim that I am proud to be a frontend engineer.

The defence RESTs, POSTs and GETs your feedback.

Addendum: This is also applicable to all the other jobs we have in the market. A good database engineer can save you seconds of loading time, a great cloud engineer can lower your bills and a great backend engineer make sure your servers only do the job they should and not run optimisation pipelines for a huge pile of unused frontend code. And with all the big players right now trying desperately and shortsightedly to please stockholders in times of inflation by laying people off rightsizing, the market is awash with talent. And maybe you can afford three experts for the price of one 10x full stack ninja rockstar who lives in a city where 80% of their income is their rent.