Earlier today I spoke at the Microsoft Reactor meetup in Berlin about frontend development, LLMs, ChatGPT, GitHub Copilot and what it means to our work and careers. In this 32 minute talk and 5 minutes of Q&A, I covered a lot of ground:
Introduction
Web Development isn’t complex technology
GPT can create web products from a doodle, or can it?
I just got access to GitHub Copilot CLI and a few seconds after installing it, I am happy as a clam about it.
You can see it in action in this video or let me talk you through it here. GitHub Copilot CLI brings AI code completion to your terminal. After installing it, you get three new commands:
??: Translate natural language to arbitrary shell commands
git?: Translate natural language to Git commands
gh?: Translate natural language to GitHub CLI commands
I love using the terminal, as it gives you a lot of power and it is a lot faster than other tools like Finder or Explorer. The issue is though that it is not easy to remember the sometimes cryptic syntax of bash commands and attributes of command line tools.
This is where Copilot CLI helps. Say you want to convert all the videos in the current folder to mp4 and resize them to 640 pixels width, keeping the aspect ratio. All you need to do is write `?? convert all videos in the folder to mp4 and resize them to 640px` hit enter. You get a suggestion of code that will do that task and a detailed, human readable explanation what the code does.
You can choose to run the command immediately, revise your input in case something feels off or cancel and go back to the terminal.
Another prompt I tried was `?? find all files bigger than 500mb and copy them to a folder called huge` and the result was immediate.
I like that it doesn’t only give you the result, but also explains what the code does. This often is missing from answers on StackOverflow and other forums.
It will be interesting to see where this goes. The Terminal is a mighty tool and you can do a lot of damage if you are not aware of the consequences of your commands. It would be interesting to see Copilot also give you some safety instructions with every command it offers.
Posted in General | Comments Off on GitHub Copilot for the Command Line is amazing!
I was just about to write a blog post on my current experiences in trying to find a new job. I wanted to write about the frustrations and how it feels ridiculous that developers and recruiters aren’t best friends. And then I remembered that Microsoft Edge now comes with a HUGE Bing icon that promised ChatGPT functionality right in the browser.
So I pressed the b, went to the “Compose” tab, entered “Developers and Recruiters should be friends”, selected “professional”, “blog post” and “medium length” and this is what came out of it:
Developers and Recruiters should be friends
If you are a developer, you might have a love-hate relationship with recruiters. On one hand, they can help you find your dream job and negotiate a good salary. On the other hand, they can spam you with irrelevant offers and pressure you to accept a position that is not a good fit for you.
But what if I told you that developers and recruiters can actually be friends? That they can work together to achieve their mutual goals and benefit from each other’s expertise and network? That they can respect each other’s time and preferences and communicate effectively?
In this blog post, I will share some tips on how developers and recruiters can build a friendly and productive relationship that will help both parties succeed in their careers.
Tip #1: Be honest and transparent
One of the most important aspects of any relationship is honesty and transparency. Developers and recruiters should be honest and transparent about their expectations, skills, availability, interests, and feedback. This will help avoid misunderstandings, frustration, and wasted time.
For example, if you are a developer, you should be honest and transparent about:
Your current employment status and notice period
Your salary expectations and benefits requirements
Your preferred location, work environment, and company culture
Your technical skills, experience level, and portfolio
Your career goals and learning objectives
Your feedback on the job opportunities and interviews
Similarly, if you are a recruiter, you should be honest and transparent about:
The details of the job opportunity and the hiring process
The salary range and benefits package
The company’s mission, vision, values, and culture
The expectations and responsibilities of the role
The feedback from the hiring manager and the next steps
Tip #2: Be respectful and professional
Another key aspect of any relationship is respect and professionalism. Developers and recruiters should treat each other with respect and professionalism at all times. This means being courteous, polite, responsive, punctual, and constructive.
For example, if you are a developer, you should:
Respond to the recruiter’s messages in a timely manner
Inform the recruiter if you are no longer interested in the job opportunity or if you have accepted another offer
Show up for the interviews on time and prepared
Thank the recruiter for their time and effort
Provide constructive feedback on the job opportunity and the hiring process
Similarly, if you are a recruiter, you should:
Respect the developer’s time and availability
Tailor your messages to the developer’s profile and preferences
Provide clear and accurate information on the job opportunity and the hiring process
Follow up with the developer after each interview stage
Provide constructive feedback on the developer’s performance and potential
Tip #3: Be helpful and supportive
The final aspect of any relationship is helpfulness and supportiveness. Developers and recruiters should help and support each other in achieving their goals. This means sharing useful resources, advice, tips, referrals, recommendations, and encouragement.
For example, if you are a developer, you can:
Ask the recruiter for tips on how to prepare for the interviews
Share your portfolio or GitHub profile with the recruiter
Refer other developers who might be interested in the job opportunity
Recommend the recruiter to your network or leave a positive review on their profile
Congratulate the recruiter if you get hired or wish them good luck if you don’t
Similarly, if you are a recruiter, you can:
Provide the developer with relevant information on the company and the role
Share your insights on the market trends and salary expectations
Introduce the developer to other hiring managers or recruiters who might have suitable opportunities
Recommend the developer to your network or leave a positive review on their profile
Congratulate the developer if they get hired or wish them good luck if they don’t
Conclusion
Developers and recruiters should be friends. They should be honest and transparent, respectful and professional, helpful and supportive. By following these tips, developers and recruiters can build a friendly and productive relationship that will benefit both parties in their careers.
Isn’t this bonkers? It is well written, it gives really good advice, it even feels like it is written by someone with lots of experience and empathy for both sides of the argument. And it is well structured in headings and lists to be accessible (albeit probably not here as I put a blockquote around it) and SEO optimised. Sure, there is some repetition that betrays its origin, but with a bit of editing, you could have an article that looks good, feels great and is generic enough not to annoy anyone.
And that is the issue, isn’t it? When I started blogging in 2005, my blog was a scratchpad. I learned something, and I wanted to write it down so that I don’t forget it. It was messy, it was at times plain wrong (but at the time OK) and I didn’t give a damn about its SEO. I always made sure I do the most I can to be accessible, but all my Google juice came by accident and word of mouth.
What does that mean for people who want to start writing and having their place on the web now? Personally, I think if you try to optimise for search engines or social share-ability you’re in for a lot of frustration. Or you can do what I did and let the machine do the work. Black hat SEO (and those with a dirty grey hat) have been content farming for years and generating nonsense articles full of links and keywords. Some of that was automated, but now the floodgates are open and anyone could create a clever sounding blog or even online magazine with a few clicks.
Instead, I think this is a great time to be, well, human. To write what you want to. To admit to your errors. To show what excites you and why and not write a “7 ways to use XYZ to boost your ABC”. I’ve been around this for a long time, and the people I do remember, still follow and keep telling others about are those who allow themselves to be a person, and not a “content creator”.
Shine on, you fabulous whateverthehellyouare !
Posted in General | Comments Off on This is the time to be unpredictable and human
When GPT-4 was announced earlier this month, one of the demos made a massive splash: painting a web app on a napkin and getting the “AI” to create the HTML, CSS and JavaScript to make it work.
This caused an avalanche of news items and blog posts calling “game over” for web developers and that soon all the work to build web products will be done by machines. Any person will be able to do that job – all you need to do is to ask the chat bot the right questions.
What you see is what you get?
This is a very old idea and dream. When I started building software, there was Visual Basic, which allowed me to drag and drop buttons and form elements in a visual interface and it created code under the hood. Borland C Builder did the same. Then Netscape Communicator came with Composer, a WYSIWYG (What You See Is What You Get) editor to build web pages. Microsoft Frontpage did the same and so did Macromedia Dreamweaver.
Each of these web tools had one thing in common: the code they created was abysmal. The reason isn’t that the tools were bad. The reason is that starting any web based product as a graphic is limiting it to one state.
Building things for the web means separating the look from the functionality
Web products by definition aren’t looking and working the same everywhere. They do instead give people who use them the best possible interface fitting the form factor of their device. On Desktop, this could be a multi column layout, on mobile it is a single column layout with fewer interaction items and bigger buttons as a finger isn’t as detailed as a mouse cursor is.
Even more important: our end users often have to and will change the interface to their needs. This could mean larger fonts, turning off animations or using a high contrast mode. Others might have to zoom in to 400% and only see a small part of the screen at a time. And a not insignificant part of our potential users won’t be able to see the page at all. Instead, they will listen to it and navigate it by headings and links. Others might use something like a reading mode of the browser to make it easier to consume what we put on the web.
And this is where our craft comes in as developers and designers. We need to build something resilient enough to work in all these circumstances. Good developers understand that when it comes to web development, we are not in control. Our users are. Our job isn’t to build an app that shows a joke when you press a button. Our job is to create the right piece of code that allows users to consume a joke when they interact in some way with our product.
The main task is to separate the content from the functionality and the look. Any web product should be able to get a different style sheet and look vastly different. Removing a button or adding a new feature should not mean having to re-create the whole product. The interface should be modular enough to allow for that.
WYSIWYG Footguns
It is understandable that people get excited when they can create whatever they want and “paint” an app or a document. But it always comes with the problem that it won’t be possible to change or style it differently. You don’t even need to go into design to witness this. How often do we get Word documents from people that don’t use any formatting? Instead of selecting the headline format, people bump up the font size and use colours because they look good at the time and on their computer. People who rely on the document structure to navigate it can’t find any and won’t be able to read the document at all.
I really love the idea of allowing people to build things for the web without having to write any code. And there are many solutions out there that already deliver that. The best ones allow you to pick from components and assemble an interface that way. And this is where we should be going. It is not about painting an app, it is about assembling them from working, independent parts.
I welcome our AI web-development overlords
Many other people have said the same: I am not worried at all about our jobs as developers. When it comes to Prototypes, Slideware, Brochureware and Proof of Concepts it is great that we could get them generated with a prompt in an AI system. We iterate in design research using paper prototypes and many a developer’s valuable time is right now wasted building things for the bin. Something like the joke app does not have to be done by a professional developer. Its a fun thing to create and try out. Much like anything you do in a hackathon or when you’re bored and got some time to play. It is not a web product though and it is far from production ready.
It will be interesting to see where we go with this. I am all for democratising web development and I love to see what browser-based tools like Figma, Canva and others already do now. We can create tools that allow people to “paint an app”, and we should look deeper into how we can have these tools create components that make up a bigger thing rather than a graphic turned clickable prototype.
End of May will be my last day at Microsoft and I am actively looking for a new role. Thank you in advance for any connections, advice, or opportunities you can offer.
What I am looking for:
A technical lead role – CTO, Technical Director or Principal Product/Program Manager
A team to work with and cross-organisational impact
Hybrid/Remote work from Berlin, Germany (very open to travel)
An Open source / public community aspect
A competitive salary of what I am having right now ( new Intl.NumberFormat(‘en-uk’, { style: ‘currency’, currency: ‘EUR’ }).format((Math.PI*`1${‘0’.repeat(5)}`/2|0)) )
I bring:
20+ years of development experience in the web/app space
15+ years of working with the biggest web sites and companies (Yahoo, Mozilla, Microsoft)
10+ years of team leading experience, mentoring and training
20+ years of experience in working remote and with distributed teams in India, China, Europe and the US
Deep knowledge of web technologies, accessibility and legal compliance
Deep knowledge of agile methodologies and continuous delivery
Proven track record of creating, planning and releasing products with > 1.5M downloads and 40k daily active users
Thought leadership track record (blogging, social media, keynote speaker, video courses)
A deep understanding of the needs of developers
Excellent communication skills and experience in working cross-department and companies
Fluent bilingual in German and English, OK in French
Please contact me per email, or – even better on LinkedIn with opportunities. Also happy to help out anyone who is also looking!
Posted in General | Comments Off on Looking for a new opportunity
