Permission to Flail

Just some trees

I was chatting today about student projects. As you do. I was wondering if there should be a period at the start of a project where folks should spend a while just flailing around with stuff. I find that when I’m starting a new project I tend to spend a while trying things and finding that they don’t work. At the time I’m doing this I can get a bit stressed because I don’t seem to be making any progress. However, after a while I find that things start to fit together a bit and some of the things I discovered while I was flailing around turn out to be useful. And other things might end up being used in a totally different context.

I’m now a lot more relaxed about flailing. I see time spent failing as actually useful. Of course flailing is only fun if the pressure level is lower. If the deadline is tomorrow flailing is no fun at all. But, if you manage your time correctly (top tip: always start before when you think you should) then you should be able to factor in a couple of days of flailing. I even suggested that there might be a formal period in a development project for some unstructured flailing around. Maybe flailing could become a thing. Here are my top tips for flailing:

  • Do it at the very start of the project, not when the deadline is close

  • Keep a very good log of what you’re doing. If you are using ChatGPT (a useful ally in the flailing process) you can ask it to summarise what you have just done and then you can drop that into your log.

  • As soon as you find an approach that you think might work, you are allowed to stop flailing and move onto the next phase.

  • Don’t regard it as a waste of time. It’s not. But if you have flailed for a while and nothing pops up it is best to step back from the project for a while (as long as you have time) and then come back to it.

The Future of Work

I asked DALl-E-2 for a picture of an undertaker doing plumbing. I think artists don’t have much to worry about at the moment….

Today I got asked the question “What is the future of work?” by Kofi at Radio Humberside. There’s a lot of concern about the machines taking over. I thought I’d write down what I was thinking.

Humans won’t be replaced by machines. Some human roles will be replaced by some machines. We really need to have a grown up discussion of the role of work in a fulfilled life. Perhaps that will mean holding back on automation. If people don’t have jobs to do, how will they get fulfilment?

Work will be different. We’ll use machines for the “easy” stuff and save the people for the hard bits. Knowing things might not be enough to get on in the world. Being able to describe things might not be enough. Being able to program might not be a long-term thing either, as machines get better at understanding what we want. I’ve got serious doubts about programs written by AI, but AI does make a great “keen assistant” which means we might need program writers. Not knowing about the new tools is not a plan. Figuring out how to use them is. Learn how to talk to the new AI. And get good at asking the machines questions. You can get a lot more out of them by asking your questions in the right way.  

Just like electronic keyboards and music sequencers let lots of people into the music business back in the day, tools like ChatGPT can help people with ideas but nowhere to take them. If you need a business plan, a product description or even a devil’s advocate to spot flaws, then you should use AI. Keep having ideas. Keep doing things. Keep putting yourself out there. Look at everything you do and ask “How can I build my brand from this”. Don’t prepare to do one thing, prepare to do lots of things. And do lots of things to find out which ones you like.

And make you keep up to speed with the bad things that new technology makes possible. If you can use AI to write a business plan, you can also use it to write very plausible and personalised lies. And you can add very persuasive fake pictures and video too. The world is filling up with untruths and the people that distribute them don’t seem to care. So be careful out there..

What is DNS?

A survey released today reveals that not many people know what “DNS” stands for. It’s a computer networking term that specifies the system used to convert internet names into the physical address of a computer. They say that this is bad, but I think they were asking folks the wrong question. If they’d asked folks “what is robmiles.com?” most of them would probably have said it’s an address on the web. Which is just about all you need to know about DNS.

What folks do need to know however is that robmiles.com costs me a few pounds a year to keep active, and that when I set it up nobody checked that I was really Rob Miles. A Domain Name (which is what robmiles.com is) can be bought for a tiny price and there is no process of checking that the names represent what they imply. Today I can buy the domain name “bbcradio.media” for less than two pounds. I can then set up websites with that address and pretend to be the BBC

You could be the BBC for less than a couple of Quid!

So the important thing to know is that internet addresses are easy to get and very cheap, which means you need to be seriously careful when you go onto the internet and start looking for things. You also need to be careful when you get emails from people claiming to be from a particular organisation or company.

When in doubt - rebuild everything

Working work in progress

I’ve spent the last week trying to get an ESP8266 device to host a configuration web site for my Connected Little Boxes. It’s proved to be quite a challenge (see Monday). I had the worst possible fault. One that only appears every now and then. And causes the whole thing to just crash.

In the end I decided to go back to first principles and run one of the example applications in a brand new project. And it worked a treat. That’s good because I now know that what I’m trying to do is possible (always useful knowledge) but bad because my code still doesn’t work. In the end I migrated all my code into the working example and went from there. In the process I discovered that, for whatever reason, the code I had been using was based on very old driver code for the device. Early versions of the ESP8266 libraries were known to be a bit buggy and unreliable. I thought that mine had been updated as part of the normal behaviour of PlatformIO (which I’m using to build and mange the app). This turned out not to be the case.

So - if you’ve got problems that you don’t think are your fault, it might be worth checking to see if you are using the latest version of the libraries for your product. Of course, new versions also bring new bugs of their own, so make sure that you keep copies of the old version too…..

Don't make everything a challenge

This is actualy how it looked when I was working on it…

I personally think that a bit of failure is good for you. But not too much. One of the better ways to fail is to turn something into a challenge. Today I was faced with something broken. I figured out what was wrong and how it could be fixed. And then I tried to fix it. It looked like an interesting challenge. Of course I failed. It turns out that it was a bit more challenging that I expected. Perhaps with more time and more patience I could have completed the job but I ran out of both in the end.

I was just asked to find out what the problem was. I wasn’t expected to fix it - which made the challenge all the more enticing. The good news is that I did learn something (you should always learn something from your failures). The thing I learned was that sometimes the best thing to do is explain what is broken and then let an expert get on with fixing it. Not wade in yourself. Even (or perhaps especially) if the challenge looks interesting.

ChatGPT vs Eliza - round 2

After yesterday's post I asked ChatGPT to compare ChatGPT and Eliza. It wrote this:

ChatpGPT and Eliza are both AI-powered conversational systems, but they are quite different in terms of their capabilities and intended uses.

ChatpGPT is a state-of-the-art language model developed by OpenAI that is capable of generating human-like text in response to input from a user. It can be used for a variety of purposes, including generating creative writing, responding to customer inquiries, or engaging in conversation with users.

Eliza, on the other hand, is a much simpler program that was developed in the 1960s. It uses a set of rules and patterns to generate responses to user input, and is intended primarily as a demonstration of how computers can simulate conversation. Unlike ChatpGPT, Eliza is not capable of generating original text and is only able to produce responses based on the rules that it has been programmed with.

Overall, ChatpGPT is a much more advanced and capable system than Eliza, but Eliza has its own unique place in the history of AI.

You could believe a person wrote this, just like you could believe Eliza was a psychiatrist. But if you look closer you see a well put together pastiche of a few facts gleaned from the web, plus one paragraph straight from the sales brochure. It’s cleverly done. But I still don’t think it’s clever.

Eliza vs GPT

Many years ago there was a program called Eliza. It was very good at making people think it was human. I came across a Basic version in “More Basic Computer Games”, typed it into my Micro-Tan and got it working. It was great fun. It pretended to be a type of psychiatrist but all it ever did was parrot back to you what you had entered. My favourite bit of the code was the part which changed "I” to “Your” and “Me” to “You” etc so that it could be sent back to the user as if the computer understood what you had just written. What struck me about the reaction of other people to the program was how easy it was to make them think the thing understood what they had entered and, which is much more scary, how keen folks were for this to be the case. They really wanted to believe the software was properly clever. Me, I just wanted to type in things like “I’ve just shot grandma” so that I could get back the response “You’ve just shot grandma? Tell me more about your family”.

I was strongly reminded of Eliza when Ross was showing me how good ChatGPT is at writing programs. He asked for some Arduino code to make lights flash in response to sensors and what came back looked like fairly convincing C. It was very impressive. But it it is still not clever. It is just taking a bunch of stuff from you, looking things up and then crafting a response that chimes with what you expected to see. Sometimes it might combine things in ways you don’t expect, sometimes it will find things that strike you as original. And it might react differently from Eliza if you tell it you just shot grandma. But I don’t think it’s clever like we are. That’s not to say that it won’t change the world though. It will. For one thing search engines are going to get a lot easier to use and a lot more conversational. For another, the essay and the programming exercise are about to get massively devalued as a way of assessing knowledge. Some students will use ChatGPT to craft their submissions. Others will question why they are being asked to write something which can be done better by a machine.

For me the hardest thing about writing and programming has never been about turning out the prose or getting the code to work (although it can be fiddly), it has been working out what the program needs to do or thinking up a good subject and then crafting a narrative that works well with it. I like to think that with more of the “grunt work” out of the way with tools like ChatGPT we could focus our efforts on these human parts of problem solving. I’m looking forward to playing with it.

Get them journalling

A while back I mentioned some discussion on first programming languages for four-year-olds. I’ve been thinking about all this. If I could teach a child to do one thing from very young, it would be to start a diary or a journal.

One of the biggest regrets of my life is that I can’t remember that much of it. I’m lucky. I’ve been blogging for a while and I can go back and look at my posts from 20 years or so ago and get an impression of what I was up to. But if I’d had a proper journal I’d have a lot more to go on, including all the things that happened but are not for public viewing.

I envy the young of today who will grow up with a hinterland of pictures and sounds that will always be with them. Me, I can hardly remember what my bedroom looked like when I was 10. Perhaps 4 years old is a bit young to be emulating Samuel Pepys but getting the habit of putting in effort to remember what you’ve been up to is a really good thing. And these days there must be tools out there that you can use to get started. And writing a jounal does something else for you too. It gives you a reason to write and get better at it, which is a skill that will be useful whatever you end up doing.

What makes a professional developer?

professional Developer.png

One of the things I used to get asked by students years ago was “What makes a professional developer?". I thought I’d have a go at answering the question:

It turns out that the difference between an “amateur” and a “professional” developer is that the professional developer gets paid for their work. You become a professional developer just by selling something that you’ve made. A successful professional developer is one who creates happy customers. Consider this application:

connectToWiFi(ssid, password);
connectToMQTT(host, username, password);
while(true) {
    float x = fetchReading();
    sendToMQTT(x);
    delay(10000);
}

This is code for a data logger. It connects to the Wi-Fi and an MQTT broker and then reads and sends data values every 10 seconds. It works (which is the nicest thing you can say about a program).

The problems appear when you consider questions like “What would happen if the Wi-Fi connection fails?”. In the code above the sendToMQTT function would get stuck and the device would need to be turned off and on to get it to work again.

You might be happy to live with this, but your customer might not. Your customer would be even more upset if they only found this out after they have lost thousands of data readings because their network failed for a few seconds.

A “professional” developer would have to do one of two things: make sure that the customer knows about this “product feature” beforehand, or make the device deal with network failures.

“Going pro” means that you will have to spend more time looking for things to worry about before your customer does, but it will also lead to an improvement in everything you make.

Rob's Podcasting Tips

podcasts.png

I’m still not sure why I decided to make podcasts by reading out all the first drafts of Begin to Code with JavaScript. But I must admit that I’ve learned a lot by trying to do it. Here’s what I’ve learned so far:

  • Don’t read from a script. Unless you are very (and I mean very) good it will sound like you are reading. If you listen to my earlier efforts you can tell that I’m reading words what I wrote. In later podcasts I’m using my words as a starting point for what I’m going to say which sounds a lot more natural. By all means have some notes, but don’t write down exactly what you are going to say.

  • Have something for your hands to fiddle with while you talk. My mind tends to be able to run faster than my mouth (which is surprising) so I have something to fiddle with to keep bits of my brain busy that would otherwise run ahead and make me trip over my words.

  • Don’t have a squeaky chair (or indeed anything else).

  • Make sure you stay a constant distance from the microphone. I do this by using a headset mic, I’ve always had real problems using desktop microphones. Other tricks include putting your elbows on the desk to stop yourself from rocking backwards and forwards.

  • Don’t sweat the fluffs. If you make a mistake don’t go back and edit, just make a joke of it and carry on. I can guarantee that the second time you try to retake something you think you got wrong the first time, you will be a lot more nervous and inclined to get it wrong again….

  • Find a style that you like and grow into it. I’ve noticed that my podcasts are getting better (at least I think this is the case) because I’m now more relaxed and at home with what I’m doing. I seem to be establishing a relationship with a listener even though I know that at the time (and probably afterwards) there is nobody there.

  • Force yourself to listen to yourself. I don’t like doing this, but I do try to make constructive notes to myself to try and make the next podcast better.

  • Try to enjoy it. I quite like doing podcasts and that for me is a good enough reason for doing them (although you can regard this as a form of public speaking and therefore very, very useful to get good at). It doesn’t really matter if nobody listens, just by trying to do this you are adding value to yourself.

You can find my podcasting efforts here. I’d love to hear what you think of them.

Software Engineering Philosopy

This picture is one of mine. You can find it on Flickr

Had an email from a Peter who’s reading the C# Yellow Book at the moment. He asked about how to learn more about software engineering. I quite like my reply, so I’m putting it in my blog….

I worry a bit about too much emphasis on "software patterns". I just tend to write code that solves the problem, and then discover afterwards that I've used a particular pattern. Things like "dependency injection" just seem like programming common sense to me, but then again I have been programming for a very long time.

By all means read up on the different patterns, but do it from a perspective of refining your technique, not finding a quick solution to a problem. If you use a pattern without understanding how it really works that can end badly.

My strong advice is just to keep writing code. Build your knowledge and develop a habit of looking at existing systems and trying to figure out how you would make them work and what design decisions were made when they were created. If you do it right you’ll be learning new stuff and having new ideas all the time. I still am.

A lot of programming and software design is down to practice and experience, just like any other field. And you also need to remember that any working system is built up of compromises and that it is very rarely that you will find the best solution. You might find the fastest, or the smallest, or the quickest to build, but not the best.  So decide what kind of “best” that you want, and go for that.

Make a name by making stuff

Been getting some lovely emails over the last few days from people who have been reading my books, learning to program, and trying to make it "big in this business". The question seems to be "How do I get into programming/game development?". Here's one of my replies:

"It turns out that the best way to become a Game Developer is develop games.

Just have a simple (and keep it simple) idea for something and try to make it work. Take a look at the games that are in your books and see if you can modify them to behave differently. Change the images, make them do something different and then go from there.

I'd also advise you to get involved in things like Game Jams, where you can team up with other people and get help. That gets you feedback too. Global Gamejam has just been and gone, but anything like that (there might be some locally) are a good idea. 

If you can't find a gamejam, hold your own. Get some friends together and try to build a game over a weekend. Start with something simple that works and see where you go. And if you start blogging about what you are doing, helping other people and taking part in forums you'll get to know other developers and also start to make a name for yourself.

It will be a lot of hard work and you will need to be very persistent, but I know it can be done because I've seen people do it. "

Sometimes it's a good idea to pause when things are going well

Today I've been writing code. I love writing code. Perhaps too much. If a program is going well I have to reminded to do things like eat and drink etc etc. 

This was one of those occasions. But as I was munching my sandwich I came up with a way to make the program even neater. If I'd carried on at full speed I'd not have spotted this for a while and then either missed out on a trick, or had to do some rework later on. 

Having thought about this a bit more I think that it is actually quite a good idea to walk away from a programming task for a little while and go back to it, even if you are coding up a storm at the time. On any programming project (particularly programming coursework) I strongly advise people to start early so that they have time to fail. But it also means that you can stop and smell the roses every now and then, and this can make the result even better. 

What to make over summer

David was kind enough to invite me into South Hunsley School today to give a talk to some computer science students seeking a bit of direction for the summer. I wrote a few notes, and I though I'd put them in a blog post too. I

What to make?

If you have a long summer stretching ahead of you and you are wondering how best to spend it Computer Science wise, here are a few tips. 

What language?

I don’t care about the language. Anything you use to practice programming is fine by me. Sometimes it helps to use something you know, but then again you will be expected to know many languages when you go out into the big wide world. Don’t get sucked into “my language is better than your language” debates. The best language is either the one you enjoy using the most, or the one you get paid the most to work with. End of.

I like C#, Python and C, along with a bit of assembler. But things like Ruby, Haskell and Prolog are great if you want to stretch your brains a bit. Take a look at codeacademy.com for online training.

What application?

Build what you like. Think of something you might find useful and have a go at that. Keep it simple and don’t add things. Every idea you have will make the job bigger. Write your ideas down, but don’t feel obliged to act on them. Take a look at hardware. I love the Arduino, I love robots, and I think you should have a go at this as well. You get the bonus of learning a bit of electronics too.

What for?

To find out if it is possible. To find out things by accident. For fun. It’s important to regard programming as an experimental exercise. Sometimes people write programs just to see if they work, or what they will do. Don’t be afraid to do this.

What with?

My strongest advice is to get yourself some Arduino kit and have a go at embedded development. Pick up a Sintron kit from ebay (search eBay for Arduino Sintron) and play with that. Buy one extra stepper motor and then you can think about making moving robots. Take a look here for help getting started and some things to do. 

What else?

Make sure you write about what you have done. Make a blog, get a domain, put your code on GitHub. It might be that only 10 people read about what you built, but if one of them offers you a job on the strength of it, it is worth doing. Employers prize the ability to write well and quickly, regular blogging will make you into a much better writer. And give you a destination on the web.

Moving On

The University of Hull has been part of my life for over forty years. I arrived at the place in 1975 in tastefully flared trousers and I've been here ever since as student, duty programmer, computer manager and lecturer. And today I've begun the process of moving on from the university.

I guess it stated nearly a year ago, with congratulations from LinkedIn about my 37 years in employment at Hull. I'd never done the maths before and the number shocked me a bit. It was like a bit of grit that you get in your shoe, It irked,

As the year went by and I did my various jobs I began to reflect that I've been doing the same kind of thing for a long time and, fun though it is, maybe there are other things I might like to do which would be fun too. And maybe it would be interesting to find out. The little bit of grit in my shoe got too big to ignore. 

So, today I formally informed the university that I'd like to move on from the institution on the 30th of September this year. I'll be around for the next four months, setting up courses and getting things as sorted as I can for the next session, so I'm not going just yet. But moving on I am.

It's going to be a wrench, but it had to happen sooner or later, and I really hope I'll be able to retain some links with this fabulous institution, maybe they'll let me come back and run the odd competition and deliver the occasional Rather Useful Seminar.

I've not made any firm plans going forward. With a bit of luck I'll be able to speak at a conference every now and then, and of course robmiles.com will rumble on. My book will be out later this year and I might think about "C# Yellow Book - the Movie", but we'll have to see. 

I've got tons of toys that I've not had time to play with, I plan to spend some time fiddling with them and writing about what happens. I've decided to re brand myself "Technical Author" just for now... Definitely not retired.

I've had a wonderful time at Hull University and I want to thank my colleagues in Computer Science and of course all the wonderful students that we've had over the years. I'm actually quite nervous about the future, but I'm also rather excited. 

Floppy Disks and Nuclear Missiles

I like writing stuff for The Conversation. They take my mangled prose and turn it into really nice articles. I've just written another one for them. You can find it here. It's all about legacy systems. 

Above you can see a legacy system I helped to make. We installed it quite a while back and saw it go from "Advanced Touchscreen Magic" to "hard to find the hardware drivers" to "replaced" over twenty years or so. I'm quite proud of the fact that I don't recall it ever crashing. Except that one time that when a chap blew up all the power supplies in the building when he was testing the UPS. And that wasn't really our fault.

We should stay in Europe

I'm going to post some of my favourite European pictures over the next few weeks

Now, I'm not a particularly political sort. My line on politics is that no matter who you vote for, the government always gets in. But every now and then I feel that I have to say something. Not that I think what I say matters particularly; it's just that I feel better having said it. 

There's a lot of kerfuffle going on about Europe at the moment. Should we stay? Should we leave? I'm strongly in favour of staying in. Very strongly. I think that leaving would be a very bad plan. There's a saying that goes "Prediction is very hard, especially about the future", so I'm not really basing my opinion on any particular "facts" going forward. It's just that I like being in Europe. I like going to abroad and feeling part of the place. I like the idea that we have some common purpose across the continent. I like the way that people come into this country and pick up bits of our culture, and bring us some of theirs. I even enjoyed the Eurovision song contest this time round (but mainly because it was very, very well done).  

Leaving Europe just seems such a cold, pointless thing to do. Are we so uncertain of our national identity that we have to prove we can go it alone? I have this image in my mind of a bunch of wagons in a circle with bears and wolves roaming around outside, and the idea that one wagon would suddenly up sticks and head out into the wilderness on its own seems unnecessary and dangerous.

So I think we shouldn't do that. 

One thing I am keen on though, is making sure that everyone has their say in this. It really is a rather important decision. If you haven't registered to vote (and you should, which ever way you feel about it) then register here