Build, Run, Repeat - page 2
This week has been a pretty relaxed one, as I’m transitioning between two jobs. I’ve tried to keep a habit of my working hours however, just to keep consistency. This has meant tinkering with a lot of new things! I’ve been diving into the world of React and Azure Functions, I’ve even had a bit of a play with Monogame! But I think the most exciting lesson for me came from doing my first bit of infrastructure as code in Azure. Nothing fancy, in fact incredibly simple, and this isn’t going to be a guide on the how. Instead I wanted to touch on why you should be considering the approach as an extension of your development, rather than just something you do at the end to host/run your code.
Domain is one of those words I almost never heard before becoming a software developer, and now I hear it pretty much every day. The traditional definition comes from defining an area based on who rules it - and it’s why it came to be associated with domain names. But in software development, it’s typically used as a shorthand for a particular area of knowledge - the classic “Jordan has good domain knowledge on this, we’ll bring them into it”. What I’ve found is there can be confusion on what exactly domain knowledge means. Some strongly associate it with the technical aspects, others the business and it’s requirements. Neither of these viewpoints are wrong, but in all things, confusion and misunderstanding will bring unnecessary pain.
Back in the halcyon days of 1968, an engineer named Douglas Engelbart gave a presentation, nicknamed “The Mother of All Demos”. If you’ve got the spare couple of hours, you should absolutely go watch it, however here are some of the things demonstrated.
A lot of this week has been spent digging around in Selenium (recently discovered it has a pretty nice C# implementation) and throwing it into release pipelines. That’s a topic that has been done to death in various ways, so this week I’m writing about something which is more from my design background - but has been incredibly helpful in my time as a developer. That being the process of figuring out if you’re asking the right questions - and if you’re not, how do you craft that right question? “Garbage In, Garbage Out” applies as much to delivering software as it does to data science, after all.
subscribe via RSS