A couple of months ago, I (unsuccessfully) attempted to do a 30 day posting challenge on LinkedIn.
The challenge I set myself was to read 10 pages a day of ‘The Pragmatic Programmer’ and share the most pragmatic tips every weekday.
It didn’t really go as expected.
My first post (https://www.linkedin.com/posts/mazalkov_pathtoswe-activity-6757238298713837568-T-_g) did fairly well, and people seemed to be interested.
By the time I reached the end of the challenge (https://www.linkedin.com/posts/mazalkov_pathtoswe-activity-6771119516647739392-E2X1) engagement had dropped completely.
I wanted to share the same lessons I was learning with my network, but there didn’t seem to be sufficient interest to maintain the posting…
If you’re anything like me, you spent the last few weeks before uni browsing YouTube on how to get a first, how to manage your time, what to bring and enough ‘day in the life of’ videos that you started feeling like a student.
Lots of learning material, which is great, but how much of it did you actually take away and use? Watching and reading content on how to be more productive is great, but most of the time it’s pretty generic advice which can’t be actioned. …
If you’re in the same position I was (admittedly only a few weeks ago), you’ve probably heard or come across Product Management, developed a liking for it, and are now searching for a quick way to jump in and start learning.
This is the guide for you.
No need to fluff up the post any longer, however I feel this disclaimer is necessary. I am a beginner to the professional aspects of Product Management, and have only recommended these resources based on the advice and tips from people who had sufficient credibility. …
Piña coladas in parallel.
As beginners, we’re taught that programming is sequential.
Do this, then do that, and do this if that.
But for larger projects, the milliseconds it takes to execute an instruction quickly add up when you have hundreds, or even thousands, of lines of code.
This is where concurrency comes into use: running separate parts of the program at the same time to make the overall time faster.
A busy bartender serving multiple piña coladas would take much longer making them one by one, than by splitting the tasks up where possible and performing them concurrently:
Don’t write dodo-code.
Sometimes code will rely on values that are subject to change after the program has started executing. Different environments, different customers, all situations leading to different values.
These values are configurable, and so should be store outside of the application. Since they’re so critical to the configuration of the program, it makes sense to store them in a separate configuration (AKA config) file.
Most of the time, this is done through a “static file”: a file or database which is read by the program each time new configuration details are required.
In the passage today, an argument…
Don’t Pay Inheritance Tax (in programming!)
Inheritance is a fast and loose way of implementing functionality based on the properties of something else: a car is a type of vehicle, and vehicles can move, have a speed, and have a location. Rather than hardcoding a car, just initialise it as a type of vehicle.
Inheritance couples components: the child class is coupled to all of its ancestor classes, and code that uses the child class is also similarly coupled. But earlier in the book, the dangers of coupling components in code were strongly shown.
Could there be a better…
Transformations transform programming.
Continuing on from yesterday’s post on programming for transformations, the passage today finished off this chapter with an interesting take on data within code.
With object-oriented programming (OOP), many objects are within your program, encapsulating data and remaining hidden from view until a transfer of data is required.
In a way that seems to go against the philosophy of decoupling, the book gives a tip to the effect of “Don’t Hoard State; Pass It Around”.
Rather than having separate objects with separate data flows, spread it out instead:
“Instead of little pools of data spread all over…
If you can’t describe what you are doing as a process, you don’t know what you’re doing.
It’s easy to forget the high-level objective of programming: take some data, process it, and output it (or make it available for later).
All programs transform data, taking inputs and producing outputs, yet this is sometimes neglected in favour of actually implementing the code in the first place.
Today’s pages present a convincing argument for getting back in the mindset of thinking of programs as inputs being transformed into outputs: to clarify the structure, to make error handling easier, and to decouple components…
Turn it off and back on again.
Untangling a mess of spaghetti code can be the least enjoyable activity to think of doing on a Friday evening. None of the processes make sense, crashes are constant, and the flow of the program starts looking more like a maze than anything logical.
As a throwback towards A Level Computer Science, as well as a nod towards my current Systems and Software Engineering Principles module, Finite State Machines (FSMs) could be a big help.
In a very short description, an FSM is an abstract machine with a finite number of “states”: the…
Things don’t just happen; they are made to happen.
Juggling the real world with a software project is tricky. Computers have limitations, and so code must be organised to respect these limitations and make sure as much usefulness is produced as possible.
But with the progression of technological innovation, responsive applications are becoming ever more popular.
Gone are the days where websites didn’t have to cater to mobile devices, or even be able to be viewed from a tiny screen on an embedded device.
Today’s reading raised an interesting point:
“Today, we expect more: computers have to integrate into our world…