This page is the first in a series of five pages about becoming a professional FPGA designer. I'm starting with an overview and a few suggestions on how to start off.
Introduction
This series of pages is for you who want to learn FPGA design — in particular if you're aiming at making a profession out of it — but find yourself lost in the ocean of information out there. So many tutorials, blog posts, video courses and forum threads. And by now, a whole lot of that material is generated by AI. It's difficult to tell what is written by someone who knows the way and what is just worthless words appearing to be professional.
If you're at the point where you feel overwhelmed by everything you're told you need to learn, you're definitely not alone. The list of things to master is genuinely long, and it's hard to tell what actually matters and what's just noise.
I'm not here to tell you what to do, or to hand you a curriculum that you must follow to the letter. What I want is to explain the purpose and importance of each skill, so that you can make your own decisions about what to prioritize and when. It's challenging as it is. If you can save yourself unnecessary work and reach your goal, so much better.
But if your purpose is merely to pass a job interview, I'm afraid I can't help you much. Job interviews are unpredictable animals. Every interviewer has his own way of evaluating a candidate, and quite often what they're looking for is a person who reminds them of themselves. After all, we all think we are the smartest person in the room, don't we? And maybe the naive approach works: if you're good, you'll find a job.
What are FPGAs used for?
Before we dig into the skills, it's worth spending a moment on what this profession is actually about. What do people build with FPGAs, how and why?
Here's the situation. Somebody needs a printed circuit board for a new product. Most of the components on that board can be bought on the market: Memories, power supplies, connectors, and so on. But somewhere in the middle of all the action, there's a function that no component in the world does, at least not exactly the way the product needs it. So you decide to design your own chip. That's an ASIC, and it's really, really expensive. The production cycle can cost more than a house, and if you find a bug after that, all you can do is to issue an errata report. And come out with a new version after a while, if there's a financial justification for that.
The alternative to this expensive and risky design cycle is the FPGA. A chip of this sort is like an electronics kit on a piece of silicon: It contains a lot of small building blocks and wires that aren't connected in a specific way. Instead, there is a large chunk of data that contains information about how the FPGA should behave. This data is referred to as the bitstream. The information in the bitstream configures each little building block inside the FPGA, and also determines how the wires inside are connected.
After the bitstream has been loaded into the FPGA, we have something similar to an ASIC: It's a chip that behaves as if we manufactured the silicon for our own purposes. Except that it's slower, it eats more energy, and the component itself costs more than a mass-produced ASIC would.
The bitstream should not be confused with software. They are similar in the sense that if something goes wrong, it's often possible to fix a line of code and recompile. But the FPGA is not a processor. It doesn't "run" anything. Think of the FPGA as a huge array of small logic machines, and the bitstream tells each of these small machines what to do.
To summarize this point: The FPGA is the missing brick in an electronics project. It's used where you would like to have an ASIC, but prefer to pay more for each component, and get lower performance, in order to reduce the development risks and costs. Which still remain high, but less so.
The FPGA designer's main work consists of the design tasks that result in a bitstream. This is comparable to a software designer writing code and ending up with an executable software binary. But the FPGA designer's role definitely doesn't end there, as the FPGA is part of an electronics project. I'll come to that later on.
If the project requires an embedded processor, that part is often part of the FPGA as well. In some projects, they choose to have the processor as a separate component. Either way, the processor might perform simple tasks or behave like a full-blown computer running Linux or another operating system.
But — there used to be a lot of buzz about FPGAs being used as coprocessors and hardware accelerators in data centers. There was also talk about FPGAs used for AI. And there are still companies that blow that trumpet. I think that was always rubbish, and by now it's quite clear that GPUs are superior in that field, especially for anything related to AI. So don't fall for that. The FPGA is used as the missing important brick in an electronics project, sometimes of a very sophisticated sort, but is quite rarely used for anything else.
Why is it difficult?
Let's put it this way: if I find myself writing five pages about what it takes to be a good FPGA designer, there's probably a lot to it.
FPGA designers are paid well because it's a complicated profession, and the reason is that it combines three skills at once.
The first skill is electronics. In the end, you're developing something that sits on a PCB, and it has to talk to the other components on that PCB. The project comprises pins, voltages, connectors, clock oscillators and a whole lot more. The logic you create talks with real components on a real board, at real voltages and real temperatures.
The second skill is "software". What you write and work with are files that look very much like software: Verilog files, constraint files, compilation scripts. But it's much more complicated to work with this kind of "software", for reasons I'll get into later on. The compiler, so to speak, isn't on your side in the same way a software compiler is, and neither are the tools you use for debugging.
The third skill is application-related knowledge. As an FPGA designer you often need to teach yourself advanced topics that are related to the project (or that you already know from previous experience or studies). Signal processing, network protocols, interface protocols with computers, standards for encoding data to computer monitors, and a long list of other disciplines that relate to the actual product you're developing. There's always a new communication protocol, a new set of safety regulations, or a new component with its weird interface requirements to learn.
But the significant challenge in being an FPGA designer is this: The project's main expertise topic is often closely related to the FPGA design itself. That means you may need to become an expert in the main technologies that your company applies. Typical examples are digital filters such as FIR and IIR, FFT, decimation and interpolation; audio and video processing; wireless and software-defined radio; radar; medical imaging; networking and packet processing; Ethernet; PCIe and USB; video standards like HDMI, DisplayPort, SDI and MIPI, with all their video timing and color space complications; and control systems. And it definitely doesn't end there.
You don't need to know all of these things in order to become an FPGA designer. But you will end up learning quite a lot of them as you go. So if the idea of learning new technologies all the time sounds like a nightmare to you, I would ask like, ehm, are you sure you want to get into FPGAs?
Do I need to be an electronics wizard?
Here's a piece of good news, maybe: The logic in an FPGA project can crudely be divided into two sorts, and one of them requires no knowledge of electronics whatsoever.
The first sort is logic for interface. This is the logic that talks to external components or to IP cores, hard or soft. Think of chips that capture or produce video signals or radio signals, RAM chips, and so on. This sort of logic interfaces with these components, and this interface is where the FPGA meets the physical world. To implement logic of this sort, you need to understand things like voltage levels, timing budgets and jitter.
The second sort is logic for processing. This is where the actual calculations happen: Video image enhancement, digital filters, organizing or parsing data streams according to a network protocol, and so on. This kind of logic typically works in one of two modes. Either it fetches data from and writes data to FIFOs or other memory elements, in which case we can call it a "pure logic" project. Or it's synchronous with the data flow, like a digital filter that receives samples from a radio signal and produces one output sample for each input sample that arrives, with a pipeline delay. This last kind is often harder to implement, because every stage has to keep up with the stream.
The point here is that implementing logic for processing requires no knowledge about electronics at all. It doesn't matter if it's what I called "pure logic" or if it's synchronous with an external data flow: Everything happens inside the FPGA, and the outside world is irrelevant for the logic design. It's therefore the easiest path into the FPGA world. There's a catch, though: There isn't always much of this kind of logic in a project. Besides, in a small company you'll be expected to do a bit of everything. There's no escape.
There is no "typical project"
If you go looking for descriptions of how an FPGA project unfolds, you'll find plenty of nice diagrams. Take them with a pinch of salt. Reality is messier, and here's why.
First of all, the PCB is often developed before it's clear what it's going to do exactly. That sounds insane, and sometimes it is, but it's also a consequence of the beauty of FPGAs: The flexibility. As long as the hardware doesn't lock that flexibility away, you can decide later what the board should be doing.
Secondly, the functions of the FPGA project are almost always developed gradually. First, minimal functionality, and then functionality is added with time. Partly because managers usually want to see something working, and partly because the requirements tend to change all the time. It's not unusual that the PCB is modified along with the project, to support new feature requirements and to solve hardware bugs.
Thirdly, it's more common to continue an existing project than to start from scratch. Even projects that look brand new often start from an existing FPGA design and an existing PCB, which are adapted to the new requirements. If that sounds familiar to anyone who has worked in software development, that's not a coincidence.
So you may come across talk about the "typical FPGA project flow": Specification, architecture, RTL, simulation, synthesis, implementation, timing closure, bitstream, bring-up, verification. Or something like that. I don't want to say that's complete rubbish, so I'll put it this way: I've never been in a project that worked this way. Some of these stages blend into each other, some are skipped entirely, and usually all of them happen at the same time. The point about being an FPGA guy is being used to everything happening in parallel.
The takeaway point is this: In a company, there's a good chance that you'll start off by adding features to an existing project. And if that project is well structured (ehm, it rarely is), you don't need to know everything from day one.
How do I start off?
Learning FPGA design is a combination of acquiring theoretical skills and gaining hands-on capabilities. It's up to you whether you prefer to play around with electronics first, or to learn the theory first, or to do a little of each all the way through. All three approaches work.
There's one thing I'd like to warn you about, though: Be careful not to learn from FPGA hobbyists. This can be counterproductive, seriously. The main difficulty in the FPGA profession is to get a reliable design. Hobbyists generally don't care about that, because they're not building a product that has to work in the field for ten years. So they often offer a quick and short path, skipping the small and crucial details necessary for a professional FPGA design. You'll get really bad habits learning from them.
How can you tell the difference between a hobbyist and someone you want to learn from? It's difficult to know what's correct and incorrect before having the knowledge yourself. But you can get a hunch if the writer has the right meticulous attitude towards FPGA design. I describe the right kind of personality in the last part of this series.
With that said, here's how I'd suggest you get your hands dirty.
The Internet is full of example projects. It's usually easiest to start off with an FPGA project that is tailored for your specific board. Such projects often exist as part of the package, precisely to encourage you to buy this or that piece of hardware.
Begin with a simple blinking LED project. Not because blinking LEDs are interesting, but because it takes you through the first full cycle of implementation and bitstream programming. You'll get the tools installed, you'll see a bitstream being generated, and you'll see something happen on the board. That's a milestone in itself.
Then try other example projects. Remember that the value of such a project is what you understand from it, and even more importantly, your ability to make some meaningful changes to the project and see what happens. A project you can't modify is a project you haven't learned anything from.
On that note, beware of vendor demo projects that come with a long line of instructions: Click this, click that, and in the end the board does something impressive. If you haven't understood anything along the way, and the project is too complicated for you to understand and modify, that project is completely worthless to you. It's a demo, not a design example.
The last, and most difficult stage, is to challenge yourself with projects you decide upon. You can get plenty of inspiration from existing projects on the Internet, but the real point is that you do it all by yourself. Unlike most published projects, the idea for your project can be useless and silly. Make a silly game with LEDs and buttons, turn the board into a musical instrument (create analog-like output signals with PWM), make the LEDs dim and blink in different patterns, whatever comes to mind. Such projects aren't usually published, because who wants to spend time on a silly idea with a pointless result? Well, it doesn't matter if the result is useless when you do it to practice your skills. The point is that it works correctly, and that you achieved that by using correct techniques. From LEDs and buttons, climb to more challenging things.
Short videos about FPGA can be useful, in particular the ones that show how to do specific things with the hardware. Longer videos are usually a less efficient way to learn, as they tend to get too wordy and unfocused.
Most importantly: Control the learning process. Decide what skill you want to obtain, and find the resources that help you obtain it. Don't get led by the nose with a series of tutorials, videos or whatever.
What board should I buy?
That depends on what path you want to start off with: "Processing logic" or a more electronics-oriented kind of experiments. I'll discuss each possibility below, but I'll start with a couple of pieces of advice that apply either way.
First and foremost, pick a cheap board. Consider it your first, and not your last. The principles are the same for all boards, even the simple boards with small FPGAs, few logic cells and not-so-impressive performance. The fancy projects you can carry out on more expensive boards usually have very little educational value. You need to get the basics right in the beginning, and virtually any FPGA is enough for that. If and when you feel you've outgrown your first board, you'll know much better how to pick your next one.
Secondly, pick a board with an AMD FPGA. Other boards may be cheaper and technically better, but AMD dominates the FPGA market, so experience with their FPGAs and their development tool suite (Vivado) is most likely to help you in the future.
Besides, other FPGA vendors do their best to make the transition from AMD to their own FPGAs as smooth as possible, in particular by offering development tools similar to Vivado. So even if you'll end up working with FPGAs from a different vendor, you still have a good start. I'm definitely not saying AMD's FPGAs are the best choice for every application, but AMD is the best starting point for learning, even if you're going to move to a different vendor later.
Out of the different FPGA families offered by AMD, I definitely suggest Artix-7 or Spartan-7. If you want to experiment with an ARM processor inside the FPGA, I suggest the Zynq-7000 family. The cheaper range of these devices is, in fact, Artix-7 FPGAs with an ARM processor added. So if you get one of these, you can use it as an Artix-7, or you can choose to work with the ARM processor as well. A Zynq-7000 is a two-in-one.
Artix-7, Spartan-7 and Zynq-7000 are pretty old FPGA families. However, the differences between them and the absolutely latest FPGAs on the market are just performance (in particular clock frequencies) and a lot of specialized logic blocks that have no significance for an FPGA beginner. If you can get a project properly done using all features of an Artix-7 (or Spartan-7), you have pretty much everything covered. No need to get into Ultrascale, Ultrascale+, and Versal.
Another advantage with Artix-7, Spartan-7 and Zynq-7000: When you target these FPGAs, you can use Vivado (for Windows or Linux) completely free for generating bitstreams from Verilog, programming the FPGA and simulating your design. A wide range of IP blocks are also available for free with these devices, and the same goes for the software development kit. So you can go to great lengths with Vivado without paying for the software. Actually, virtually all FPGA vendors allow free use of the development tools for their simpler FPGA families.
If you want to pick a board with a later and "heavier" FPGA family, be sure to check if you need a paid-for license for running Vivado on that FPGA.
Equipment for "real" FPGA learning
If you want to get into FPGA for real, you need to create a small electronics lab. It's really not a big deal, and most of the things you'll need to buy are cheap and available in any electronics maker shop: Small resistors, Dupont wires, etc. You should also be sure to have a simple digital multimeter. Even the simplest will do the job. Some basic equipment for soldering can also be a good idea.
The expensive part that I suggest purchasing is a simple oscilloscope. This measurement instrument shows the voltage as a function of time. This allows you to view the signals at the FPGA's physical input and output pins. You can also view analog electronic signals, for example the voltage that drives a loudspeaker.
An oscilloscope is important, as you should learn how to use this instrument to check and debug your design. The convenient option is a standalone oscilloscope. But there are also "USB oscilloscopes" that you connect to a computer and watch the signals using a program running on the computer. It doesn't matter. Both options work. There's no need for fancy features either.
But be sure that the oscilloscope's analog bandwidth is adequate. The analog bandwidth is the limit to how fast the signal you're watching can change. Note that this isn't the oscilloscope's sample rate, which is sometimes also called "bandwidth" for short, possibly to confuse buyers. When a digital signal changes at a rate near the analog bandwidth, it's shown with smooth edges on the display, even when the transition is sharp and fast in reality. Digital signals faster than this may not be distinguishable at all.
So if you want to start off cheap, go for a 10 MHz analog bandwidth. This means that your logic design should not run with a clock frequency higher than 10 MHz, or else the output signals may not appear properly on the oscilloscope's display. Actually, it would be better to keep below 5 MHz. These are very low frequencies for an FPGA, but there's no problem with that for the purpose of making the first steps. The only problem is that you might get away with a very poorly made logic design that works only at low frequencies. So if you go this path, be sure to try raising the clock to 100-200 MHz and verify that the timing constraints are met, just to ensure your design isn't limited to very low clock frequencies.
If you can find an oscilloscope with 50-100 MHz analog bandwidth without a large price difference, I would suggest doing that. I wouldn't buy a scope with less than 100 MHz analog bandwidth for my own use.
Another thing you want to make sure of is that the oscilloscope has at least two input channels, so that you can view two waveforms at once. Surprisingly enough, two waveforms is usually enough in most practical situations. My oscilloscope has four input channels, and sometimes I use three of them, rarely all four.
And a last thing about oscilloscopes: Be sure to purchase probes as well, usually along with purchasing the oscilloscope. This is maybe less crucial when you're running at 10 MHz, but the higher the frequency, the more important it is to use probes.
So... what about the FPGA board?
With the lab equipment in place, you can now choose which FPGA board to buy. The answer is quite simple: Pick a cheap one with an FPGA from AMD. That will most likely mean a board based upon Artix-7 or Spartan-7. Or Zynq-7000, if you want to have the benefits mentioned in the next section. I'll focus on the electronics kind of FPGA setting now.
The most important thing to watch out for is whether the board has a USB interface for programming the FPGA. To explain this, I'll say a few words about JTAG.
In order to write the bitstream into the FPGA, there are several pins on the FPGA intended for lab purposes, called JTAG. This interface is also useful for other tricks (ILA in particular), but the most important purpose is to submit the bitstream from the computer into the FPGA. In the old days, there was a separate little box (often called "JTAG cable" or "JTAG programmer") that connected to the computer through USB. The other side of this box consisted of a number of wires that were connected to a pin header on the FPGA board.
Nowadays, many FPGA development boards have this functionality included. This means that you don't need this "JTAG programmer", but can connect the FPGA board directly to the computer running Vivado, and configure the FPGA with the bitstream of your design. Easy and convenient.
Simpler and cheaper FPGA boards don't have this feature, and require that you buy this JTAG programmer separately. The official JTAG programmer is quite expensive, and the unofficial ones may or may not work reliably. So for a first board, I think it's worth paying a little extra to avoid this issue altogether. At least until you're used to the workflow. Or choose a Zynq board, which can read its bitstream from a microSD card instead.
So much for JTAG. Now to the actual features of the board.
The board should have I/O that can be connected to something meaningful. In the learning process, there's great benefit in connecting the board to another small piece of electronics, maybe a development board for some analog component or something of that sort. The best learning project is where you actually develop something yourself. I therefore prefer boards that have general-purpose pin headers that can be connected to anything with Dupont wires.
I usually prefer boards with a lot of LEDs and pushbuttons on them for some direct interaction. For initial projects, a 7-segment display is also nice.
Boards often have a few peripheral components of their own. Consider if you can make a small project with these, or if that would be too complicated. For example, a lot of FPGA boards have an HDMI output jack. This allows generating an output signal that goes directly to a regular computer monitor. You will most likely use a ready-made logic block for translating the pixels into the video signal, because this is really complicated. So the HDMI output won't help you learn much by itself. On the other hand, you can learn quite a lot from creating video patterns on the video output. Maybe create a simple text display? Video art? Fractals? Display a 100x100-pixel image in a 768x768-pixel area on the screen, with correct linear interpolation? Do that correctly, and you're onto something.
So which board should you pick? Try to think about what you want to do with the board, and what equipment you have. Then pick a board that doesn't cost all that much. And once again, consider this board your first, but not your last one.
Boards with a Zynq-7000
For those who don't want to dive into electronics right away, there's a possibility to do interesting things with an FPGA regardless. The trick is to make the logic interact with a processor instead of physical signals, so no need to get physical with the electronics. The idea is to work with an FPGA that has an embedded processor. Zynq-7000, for example.
But how can the embedded processor make the starting point easier? It can, if you don't jump into the processor-related issues and its interaction with the logic fabric (i.e. the "FPGA part", referred to as "PL"). Instead, use a ready-made kit for that part that allows you to interact with the logic with simple means. If you want to dive into the details of the processor part, there's plenty of time for that later.
The easiest way to achieve this is to start off with Xillinux. This is a package that easily allows you to set up a microSD card so that your board becomes a small computer running Linux. You can attach a keyboard, mouse and computer monitor to the board, and you have a simple graphical desktop with the ability to open terminal windows as well as graphical editors. You can compile C programs directly on the board's processor with gcc and Makefiles, and run scripts on the processor as well.
However, the real point with Xillinux is that it also allows communication with the "FPGA part" (the logic you write in Verilog) with a simple interface. Based on Xillybus, the software side uses simple file I/O to send and receive data, and the logic side uses standard FIFOs for the same purpose. The important point about this way of exchanging data is that it's not an artificial trick for the sake of learning: FIFOs are the common way to exchange data in an FPGA project.
So if you're interested in designing "processing logic" (logic that gets data as input, processes it, and generates output data), you will do it the right way from the start: In "real" FPGA projects, logic of this sort usually gets the data for processing through a FIFO, and outputs its results to another FIFO. In a "real" FPGA project, there are usually other logic components on the other side of these FIFOs. When you work with Xillybus, there is software running on the processor instead. Or just a simple shell command to copy data to or from files directly into the FPGA's FIFOs.
To summarize, working with Xillinux and Xillybus gives you a smooth start, allowing you to focus on your own first pieces of logic, and test it easily with a computer-like interface. In addition, this setting makes it easy to control the logic directly from the processor, with simple computer programs or scripts. And most importantly, the whole setting is quite natural for a project that doesn't involve interfacing with the outside world.
For using Xillinux, two development boards are relevant in particular: Smart Zynq and Z-Turn Lite. These are low-cost boards that have premade kits for setting up Xillinux. There are also a few pages on this website showing things to do with the Smart Zynq board.
People not used to working with Linux may find it difficult to use the Linux system running on the Zynq-7000 processor for interacting with the "FPGA part" through Xillybus. It may also be daunting to use this relatively simple Linux distribution for developing and running software.
If you prefer a "real" computer running Linux or Windows, the same simple Xillybus-based setup can be applied using an FPGA board that has a PCIe interface. These boards are more expensive, but they can be plugged into a computer running Linux or Windows, and exchange data with the FPGA in exactly the same way. In this case, Artix-7 is definitely good enough, but you may refer to Xillybus' download page for a list of supported FPGA families.
Speaking of Artix-7, I'll reiterate that the cheaper Zynq-7000 devices are just Artix-7 FPGAs with an ARM processor on them. So it's possible to just ignore the processor, and use a Zynq board just like a regular Artix-7 board.
One difference is that a Zynq-7000 FPGA also has the capability to obtain its bitstream from a microSD card. Therefore, all that is needed to update the bitstream is a microSD adapter for USB, if you don't happen to have that feature already on your computer or laptop. Actually, you can also fetch the bitstream through the Ethernet network with TFTP using U-Boot, but that requires setting up a server, so this isn't the easiest way.
Zynq-7000 FPGAs also have a JTAG interface, just like any FPGA, but it is rarely used, and sometimes not even connected to pins on the board.
This was a lot of information, so to summarize:
- A Zynq-7000 board is a nice choice if you don't want to get your hands dirty with electronics, or if you want to try out an embedded processor on the FPGA as well.
- Consider a PCIe-based board (with Artix-7) if you want the FPGA to talk with a real computer, and not the embedded processor.
- A plain Artix-7 / Spartan-7 board is your thing if you only want a down-to-earth electronics experience.
FPGA and AI (LLMs)
Finally, let's talk about the elephant in the room. AI.
AI learns primarily from open material on the Internet, and the vast majority of this is written by hobbyists or by AI itself. The quality of AI's suggestions in this field is therefore significantly lower than, say, its answers related to software. Which isn't always that phenomenal either, but that's another discussion.
So will AI kill the FPGA profession? Nobody knows what the future holds. But let's think about what we learned from the introduction of computers and robots in the 80s. There are a few patterns worth noting.
Computers and robots replaced stupid and repetitive assignments. A lot of people indeed lost their jobs, but these were the people carrying out those assignments. The humans carrying out intelligent work remained in their positions, and became even more effective and well-paid.
At the same time, the utilization of machines is by far narrower than what is theoretically possible. In factories, humans carry out manual work that could have been replaced by robots, and this is true even in car manufacturing. But it's also true in construction, carpentry, bakeries and so on. My guess as to why is this: There's a shortage of people smart enough to use robots and computers, and an abundance of those who can learn a task by using their own hands.
The adoption of LLM-based AI will probably follow the same path. Repetitive and stupid tasks will be replaced by AI, but clever tasks will be done by humans using AI as a tool.
So the conclusion for you as a future FPGA designer is simple: Be sure to learn the profession in depth. Just knowing Verilog isn't enough. Being an FPGA designer was never just about Verilog coding. AI can write Verilog too, if it gets very specific instructions. FPGA design is mainly about making the wise decisions that produce these instructions. Turning that into code is the easiest part.
It's the deeper understanding and good judgement that AI can't replace, at least for now. And even if it will one day become possible to replace human judgement with a machine, that's the last thing to be replaced. If AI is adopted in the same way previous technologies have been, human judgement will still be done by humans.
And one more thing: Even if AI writes the Verilog code, the timing constraints, and carries out all the other tasks, a human will always be necessary for verifying that what has been done is correct, and that it's the beneficial way forward. LLMs, being some kind of simulator of brain activity, also have a human-like tendency to make mistakes. This requires a human who is competent and wise, both for guiding the AI and for checking that the AI's output is adequate. That means the future designer needs to be even more professional than today's engineer. Mediocre engineers can be replaced by AI, but that only works if an excellent engineer controls it. And since such engineers are difficult to find, it might very well be that AI won't be used on a large scale in this industry — exactly as there are still people doing manual labour in the traditional industry.
Bottom line: Whatever you choose to learn, do it thoroughly and in depth, or else an LLM will kick your bottom one day. Maybe that day has already arrived.
This concludes the first page in this series. The next page deals with the theoretical skills I find important, and also explains why I think they are worth learning.