Forem: Hasib Ahmed

Creating value and coding with a purpose - lessons by The Lean Startup

Hasib Ahmed — Wed, 30 Oct 2024 14:50:27 +0000

Imagine the scenario; after six intense months of coding, you’ve released the most intricate feature ever. Your code is optimised, unit tests are 100% green, and you’re feeling like a true engineering wizard. But... your users? They don’t care. Why? Because they didn’t need it in the first place! 🫠 Enter The Lean Startup by Eric Ries, the ultimate guide to developing products that users actually want through quick iterations, real feedback, and agile principles.

The book introduces a tech-driven, no-nonsense approach to building impactful software. For any developer aiming to ship features that deliver real value, The Lean Startup is packed with advice on how to iterate faster, learn from real users, and avoid wasting time on code that doesn’t move the needle.

1. Build-Measure-Learn: Think Better, Not Just Faster

At the heart of The Lean Startup is the Build-Measure-Learn cycle, which pushes us to break down big ideas into quick prototypes we can test with real users. Instead of crafting a fully-featured masterpiece right out of the gate, you build a Minimum Viable Product (MVP)—a stripped-down version with just enough functionality to gather feedback and validate your assumptions.

Key Takeaway:

Think about frameworks like React and Vue that allow you to quickly build and iterate on UIs. You can also employ feature toggles that allow you to deploy features behind a flag, so you can expose them to specific users for testing without a full release. And with containerisation tools like Docker, spinning up isolated environments for early feature testing becomes a breeze.

Why It Boosts Productivity:

An MVP mentality reduces overengineering and helps you focus on the core user experience. This saves you (and your team) from investing hundreds of hours into features that might not even make the final cut. Plus, faster iteration means quicker insights, which leads to smarter development.

2. Validated Learning: Data-Driven Development

In The Lean Startup, Ries emphasises validated learning: the process of using data to confirm whether or not you’re building something users actually want. This is where tools for A/B testing come in, such as AWS Evidently or through Azure DevOps for experiments. Instead of building in the dark, validated learning lets you measure actual user responses to specific changes.

Key Takeaway:

Using A/B testing tools, you can gather clear data on user engagement, feature effectiveness, and even UI preferences. Metrics from Google Analytics or services such as those from Amplitude can also help you track real-time engagement, user flow, and retention, letting you adjust before a full launch.

Why It Broadens Developer Perspective:

Validated learning forces developers to think critically about each line of code in terms of user impact, not just technical elegance. Focusing on the “why” behind every feature allows developers to make informed decisions that bring value and impact, rather than just fulfilling a checklist.

3. Experimentation and Feature Prototypes: Try, Fail, Iterate, Repeat

With The Lean Startup, experimentation isn’t just a buzzword; it’s a core principle. Developers are encouraged to create feature prototypes (or skeletons of features) that allow for rapid testing and iteration without a full-scale build-out. This agile approach makes it easy to pivot quickly if a feature doesn’t perform as expected, avoiding the dreaded “sunk cost” trap.

Key Takeaway:

Leveraging Agile methodologies like Scrum or Kanban, you can break down features into small, manageable sprints that focus on building and testing core functionality first. Story mapping and user journey mapping can also help align each development sprint with real user needs, allowing you to deliver incremental improvements and test ideas without overcommitting.

Why It Promotes Innovative Thinking:

Developers can focus on creating quick, functional skeletons that can be tested, measured, and iterated upon in small sprints. This process encourages creative, outside-the-box thinking and helps developers become more adaptable. Plus, fewer bloated features and more fine-tuned ones means happier users!

4. Listening to Customers Early and Often: Tighten the Feedback Loop

In The Lean Startup, it’s all about keeping the feedback loop tight. Instead of waiting until the entire feature is built out, developers can engage with users right from the MVP stage. This can be achieved by exposing new features to a small user segment and collecting their feedback via in-app surveys or tools like Hotjar.

Key Takeaway:

Customer feedback tools let you gather in-the-moment reactions from users. By setting up early feedback channels, you can catch usability issues, feature gaps, or misalignments early on and adjust based on what real users say.

Why It Leads to Better Code:

Regular customer feedback is an accountability system for developers. Knowing users will be testing the feature keeps the focus on functionality, simplicity, and clarity, minimising code bloat. Plus, it gives developers a real sense of accomplishment when they see users enjoying their work.

5. Avoiding Vanity Metrics and the Trap of “Success Theater”

One of the most important lessons in The Lean Startup is the need to avoid “success theatre” - getting excited about vanity metrics that don’t actually measure user impact. This can mean tracking sign-ups without engagement, clicks without retention, or installs without usage.

Key Takeaway:

Using data visualisation tools like Tableau or Grafana can help teams track meaningful metrics like user retention, active engagement, and feature utilisation. For backend-heavy projects, ELK Stack (Elasticsearch, Logstash, Kibana) can track and visualise logs to show how features are actually being used.

Why It Helps You Code with Purpose:

When developers see their code's impact (or lack thereof) on real metrics, it helps everyone stay focused on what users actually need, rather than just what looks good on a dashboard. This insight also allows teams to deprioritise underused features and prioritise high-value improvements.

TL;DR: Creating value and coding with a purpose - lessons by The Lean Startup

For developers, The Lean Startup offers a transformative approach to coding. It’s all about getting real-world feedback as fast as possible, adapting to what users want, and avoiding the “code for code’s sake” trap which is all too easy to fall into.

Here’s how you can apply The Lean Startup principles today:

🔄 MVP First: Use frameworks such as React to speed up the boilerplate creation and build prototypes fast and gather data quickly.
📈 Measure with Purpose: Use A/B testing and real user data (e.g. Google Analytics) to validate your assumptions.
🚀 Experiment Boldly: Use agile methods to deliver, test, and pivot in small, manageable sprints.
💬 Feedback Loops: Listen to users early using tools like Hotjar to avoid building features nobody needs.
📊 Meaningful Metrics: Track actual user engagement, not vanity stats, with tools like Tableau and ELK Stack.

In a nutshell, The Lean Startup gives us some valuable lessons to code not just for function, but for impact. Embrace these ideas, and you’ll build software that makes a difference—whether it’s one small MVP or a game-changing product. 🎉

Making the Most of AWS Summits: A Developer's Guide

Hasib Ahmed — Fri, 07 Jul 2023 11:27:23 +0000

Hello all fellow tech enthusiasts and AWSers (is that a thing?) out there! 👋🏼

You're probably familiar with the excitement of AWS Summits, those gatherings of geeks like us, clinging to laptops and trying to find the best free t-shirt and caffeinated drink that's on offer. It's a toned-down version of the larger re:Invent convention but still packs a lot of meaty talks. With an impressive 1,100 AWS partners and over 25,000 attendees in the recent AWS Summit London 2023, it's evident these events are more than just flashy keynotes and freebies, but there are always nuggets of knowledge hidden away.

Here are some tips for navigating your next AWS Summit, based on my own experience:

1. Welcome networking opportunities

Many attendees miss the real charm of Summits: networking. Instead of sticking with your colleagues or catching up on work, utilise this chance to interact with others. Get into conversations with engineers at the various booths, discuss potential implementations of technologies, and make valuable connections that could help you later. Remember, it's not just about sales; engineers are there for lead generation & to build connections too.

2. Embrace emerging tech

Sure the like of Datadog, VMWare, and Citrix catch your eye with their huge booths and raffle prizes. But the real breakthrough tech lurks with the booths barely big enough to fit a laptop on! Here you'll find emerging startups displaying their cool tech with the primary engineers usually at the forefront. They are interested in gaining early adopters, not just generating sales. So don't overlook these booths due to lack of flare; this is where the real technological innovations lie.

3. Study the schedule

With a jam-packed agenda, there are far too many sessions for you to go to. In retrospect, I would have devised a plan of attack to go to the most meaningful/interesting sessions in my opinion and allowed plenty of time to make my way to the theatre holding that session. Lines get very long so it’s key to be there early so you can get a seat! I would also take notes in these sessions to refer back to later for my own learning.

4. Be open-minded

Represent your efforts professionally, regardless of the company or the context. Being open-minded will allow you to see technical choices and decisions taken by other companies in a different light. There is always a reason why company X has chosen their current tech stack, or why they’ve made use of one AWS service when there are others which could be better suited. Learn from these decisions and ask open-ended questions to facilitate deeper discussions!

5. Don't miss out on swag

I’m still a novice at getting the best swag, perhaps next year I’ll imagine I’m in a real-life loot-based RPG game? Most vendors hold late-day raffles, which are fantastic chances to win some cool tech toys. However, don't hold off until the end of the day; start your swag hunt early before the best items disappear. Some notable items I scored are a few sunglasses, very colourful socks, a game emulator, lots of quality notebooks & enough trek bars to start my own store.

Some talks that stuck with me & are an interesting read:

In conclusion, remember that AWS Summits are not just about the keynotes. They're about connecting with people, discovering new technology, deep diving into AWS services in the advanced talks, learning from the decisions of other like-minded engineers and of course and grabbing some cool swag! So, next time you're at an AWS Summit don't miss out on these opportunities & most of all, enjoy yourselves!

How to deal with legacy code

Hasib Ahmed — Fri, 24 Mar 2023 13:48:47 +0000

As software consultants or software engineers, we spend a lot of time dealing with legacy code and either enhancing it for a new business use case or refactoring the original code to make it fit for a new purpose. Only some things are fantastic green field projects where you can write a whole system from scratch.

Analyse the software landscape

Much like how you would assess the requirements for a new task, this particular analysis needs to focus on the system as a whole. This means the codebase, its tests, deployment of the code and any downstream services that rely on the codebase you're working on. A couple of great starting questions are:

What is the code supposed to do? What does it actually do? How well does the code achieve its goals?
How well is the current codebase documented and tested?
How often is the codebase updated?

These questions will guide you to where the most pressing issues are. For example, if the code is updated frequently as it's a monorepo or core service, what's the deployment process like? There are likely easy improvements to make in this area to allow for a faster and higher quality of delivery.

There are lots of tools to help with code analysis and identify code coverage/code smells in order to get a more solid idea of the code quality and complexity you're dealing with. These tools should be used in tandem with speaking to the engineers working on the codebase as well as stakeholders to see where things are slowing the team down, what the business logic should be and where priorities lie for the business with the particular services you're reviewing.

Improvements to maintainability and readability of the codebase are great, but not if it comes with a negative effect on the system's performance. So always keep an eye out for the metrics in which the system is measured, e.g. response times, amount of users signing up, time taken to acquire new users, etc.

Devise a plan of action

Once you've analysed the codebase and gotten enough information to start with, it's time to create a plan of action. How will you deal with this codebase? What are the key areas for improvement?

Depending on the scope and budget of the project, various methods and approaches can be used. Two common approaches are to create a facade layer in front of the legacy code which simplifies interaction with the legacy code and only exposes key functionality. The facade layer will be built from the ground up, so you can follow a simple design pattern to keep things extensible and maintainable going forward.

Another common approach is to gradually replace parts of the legacy code with new services, keeping the old code living with the new code until fully replaced. The new services will be your opportunity to architect good software and also will be built from the ground up, you can use a design pattern if you choose to do so.

Opt for a design pattern

Design patterns are typical solutions to commonly occurring problems in software design. They are like pre-made blueprints that you can customise to solve a recurring design problem in your code.

If it fits your use case, or you're goal is to simply improve the current legacy code base, pick a software design pattern that works for the requirements you have. A good guideline for choosing a design pattern is one which makes the system easier to test.

There are tonnes of design patterns out there in the wild, so considering a few factors such as trade-offs, programming language/framework being used and the level of abstraction will help inform your decision.

See the following link to a list of common design patterns - https://refactoring.guru/design-patterns/catalog.

Test, validate and review

The last thing you need is to test, validate and then review the changes made. You need to ensure the software you've created is fit for purpose and works the way you think it does. Beyond unit testing, adding a whole heap of integration and regression tests around your services and code base will help ensure that no bugs have been introduced to other parts of the system which you haven't touched, as well as verifying things still work smoothly.

Documenting your code and its changes are key here in order to provide visibility into your codebase without someone having to read each line of code to understand your system. Once you get to this stage, it's a good point to take a step back and examine the changes you've made and if you need to reiterate in order to improve the system and codebase.

Conclusion and takeaways

As you can probably tell, there isn't a "one size fits all" approach to dealing with legacy code. The key takeaways I'd like to provide are:

Cater to your use case. Mapping through the system to find where your specific pain points are will help not only other engineers but also project managers to buy into the approach you've put forward.
Ensure you have methods to measure system performance and key business metrics of your refactor.
Keep maintainability at the forefront of your mind. You'll most likely find parts of the system undocumented, in such cases creating a README for that service/component or a runbook will help other engineers when maintaining or making future code changes.
Something that should always be considered is keeping an eye out for scope creep. It's great making a system easily extensible, but there comes additional time and complexity in doing this if there are no plans in place to actually use your extensible code in the near future.

Any thoughts you might have, feel free to comment & dicuss on this post!

Common Types in TypeScript (part 1)

Hasib Ahmed — Thu, 01 Dec 2022 18:32:08 +0000

In this instalment of the "Why TypeScript" series, we'll dive into some common types you see within TypeScript, with some code examples along the way.

This is part 1 of the common types in TypeScript, there will be a part 2 to follow which explain a few more in depth types within TypeScript.

Primitives

Along with this file, there are code examples in common-types-examples.ts.

There is a TypeScript playground where you can write, learn and share TypeScript. This is a sandbox environment in which you can experiment with TypeScript syntax in a safe area.

The TypeScript handbook includes really good introductory documentation to the "everyday types" that you will encounter on your TS journey! To add to this, there is the utility types which make common type transformations easier.

Please note the primitive types below are in lowercase. The following types: Boolean, Number, String, Symbol and Object refer to non-primitive boxed objects that are almost never used appropriately in JavaScript code. See TypeScripts do's and don'ts on general types for more information.

The following have code examples in common-types-examples.ts.

Similar to JavaScript, there are 3 commonly used primitives:

boolean

This is the same as in JavaScript, simple true/false value

const isFun: boolean = false;

number

There is no int or float, everything is number to JavaScript/TS

const pie: number = 3.14;

string

Like JavaScript, strings can use single quotes or double quotes
Template string using backticks and the ${} syntax

// strings can use single quotes
const favouriteColour: string = 'Black';

// or double quotes
const fullName: string = "Hasib Ahmed";

// template string, using backticks
const greet: string = `Salutations ${fullName}!`;

As well as these primitives, there are other basic types in TypeScript which you should be aware of:

symbol

There is a primitive in JavaScript used to create a globally unique reference via the function Symbol()
Symbol represents unique tokens that can be used as keys for object properties

// symbol
// note that both variables have what seems to be the same value
const firstName = Symbol("name");
const secondName = Symbol("name");

// if we check their equality, it will always return false & TS will give us an error
if (firstName === secondName) {
// can not happen as each Symbol is a globally unique reference
}

bigint

Introduced in TypeScript 3.2, it provides a way to represent whole numbers that are very large integers. If you're interested, it's numbers larger than 9007199254740991
You can get a bigint in 2 ways:
- Calling the BigInt() function
- Writing a BigInt literal by adding n to the end of any numeric integer
NOTE: You can only use the bigint type if you are targeting version ESNext

// creation via the BigInt function
const big1: bigint = BigInt(200);

// creation via the literal syntax
let big2: bigint = 200n;
let big3 = 100.20n; // error as this value is a decimal

null

Like JavaScript, null is used to indicate an absent value

const absentValue: null = null;

undefined

Like JavaScript, undefined is used to indicate an uninitialised value

const uninitialisedValue: undefined = undefined;

Note: null and undefined will not be factored into any type checks unless you have the strictNullChecks option enabled (this will be covered in a later posts).

any

A top type of TypeScript's type system (aka universal supertype)
TypeScripts Do's and Don'ts explicitly say not to use any as a type unless you are migrating an existing JavaScript project to TypeScript
any represents all possible JavaScript values; primitives, objects, arrays, functions, errors, symbols, etc
TypeScript lets us perform any operation we want on values of type any without having to perform any kind of checking beforehand
However, In most cases, this is too permissive and can be problematic at runtime. There is not much protection offered from TypeScript when using the any type

// any
let value: any;

// all the below are type-correct
value.trim();
value[0];
value.property.does.not.exist;
new value();

unknown

Another top type of TypeScript's type system
If a variable is not known at the time of writing (e.g. accepting all values from user input) we can use the unknown type here
You can narrow your unknown type variable to something more specific by doing typeof checks, comparison checks, or more advanced type guards
This is known as type narrowing
This is similar to any, as the value can be of any type but it is essentially safe by default

// unknown type with above code in same file
let value1: unknown;

// the following operations are no longer considered type-correct (value1[0] would not be type-correct with the strictNullChecks option on)
value1.trim(); // ERROR: Object is of type 'unknown'
value1[0]; // ERROR: Object is of type 'unknown'
value1.property.does.not.exist; // ERROR: Object is of type 'unknown'
new value1(); // ERROR: Object is of type 'unknown'

// unknown type pt2
// set unknown type to default of null for this example
let userInput: unknown = null;

// variable userInput can be any specific type, so all the below work fine
userInput = "mumbo jumbo";
userInput = 10;
userInput = true;

// simple typeof checks for an unknown type
if (typeof userInput === "boolean") {
  // TS knows that userInput is a boolean now
  // we can save this in a new const (or let) now we know the type and value
  const userInputBool: boolean = userInput;
  // within this typeof check block, you cannot assign userInput to another type
  // the following will show a type error
  const userInputNumber: number = userInput; // ERROR: Type 'boolean' is not assignable to type 'number'
}

object

Everything that isn’t a primitive type in TypeScript is a subclass of the object type
- i.e. anything that is not number, string, boolean, bigint, symbol, null, or undefined

// defining an object explicitly
const myObject: object = {};

array

TypeScript allows you to work with an array of values similar to JavaScript
There are 2 ways to write an array type
- Use the type of element followed by square brackets e.g. number[] = []
- Use the generic array type (generics will be covered in later posts/updates) e.g. Array<number> = []

// defining arrays
// method 1
let arr1: number[] = [1, 2, 3];

// method 2, using generics
let arr2: Array<number> = [1, 2, 3];

tuples

A tuple type allows you to express an array with a fixed number of elements, of which the types are known
For example, you can represent a string and number type in an array

// tuples
let person: [string, number];

// initialise in the correct order
person = ["Bob", 18];

// attempt to initialise in the incorrect order, gives us type errors
person = [18, "Bob"]; // ERROR 1: Type of 'number' is not assignable to type 'string'. ERROR 2: Type of 'string' is not assignable to type 'number'.

// attempt to initialise it as empty, gives us type errors
person = []; // ERROR: Type '[]' is not assignable to type '[string, number]'

// access correct element at index, correct type is retrieved and we can do an operation on the string
person[0].substring(1);

// attempt to access the same substring element at the incorrect index, and we get a type error
person[1].substring(1); // ERROR: Property 'substring' does not exist on type 'number'.

// attempt to access element outside the set of known indicies will error
person[3]; // ERROR: Tuple type '[string, number]' of length 2 has no element at index '3'.

enums

Unlike most TypeScript features, this is not a type-level addition to JavaScript but something added to the language and runtime s
As in languages like C#, an enum is a way of giving more friendly names to sets of numeric values
Read more about enums here https://www.typescriptlang.org/docs/handbook/enums.html

// enums
// enums begin numbering their members starting at 0
enum Colour {
  Green, // index 0
  Amber, // index 1
  Red, // index 2
}

// call element by index
console.log(Colour[0]); // Green

// you can manually set the values in the enum
enum roomInMetres {
  Floor1 = 100,
  Floor2 = 321,
  Floor3 = 5,
}

// call element by it's name
console.log(roomInMetres.Floor2); // 321

In the next post in this series we will be going over union types, discriminated unions, casting to a different types and classes!

Why TypeScript?

Hasib Ahmed — Fri, 25 Nov 2022 21:47:44 +0000

Here's my attempt to explain briefly, through a medium of text and spicy memes, what typescipt is & why you should use it.

What is TypeScript?

TypeScript is a superset of JavaScript that has optional typing and compiles down to plain JavaScript. TypeScript is technically JavaScript with static typing.

To make sure there aren't any bugs in your code, you'd usually write some tests - following test-driven development (TDD). You would also manually verify the code works, by running it, and also have a peer review (pull requests on GitHub or have someone just sit next to you and look at your code).

Using a type-checked language like TypeScript provides immediate feedback during development & can save you time and effort.

With these features, TypeScript can help you feel more confident in your code and save a lot of time checking to make sure you haven't broken the project by accident at run time since variable types are known at compile time.

Why choose TypeScript over JavaScript?

TypeScript code is more reliable and easier to refactor. This allows you to avoid errors and rewrite code a lot easier.

Types negate most of the head-scratching errors that can make their way into JavaScript code & also allows for a quick feedback loop to fix the small mistakes during code writing & refactoring.
TypeScript is less ambiguous, it allows you to focus on how each part of your code interacts with one another & makes you pay attention to how your system is actually built.
TypeScript is a superset of JavaScript, you can use all your favourite JavaScript libraries and code that you want in your TypeScript code!

This means that you can gradually start to use TypeScript in your codebase, first adding types to individual files and modules, then you'll be pushing TypeScript as much as I am.

It isn't all sunshine & rainbows over in TypeScript land, however. With any new bit of tech, be that a framework, library or, like now, a programming language - there are always downsides. Here are my top few cons of TypeScript:

Grandmasters of Java, C++ or C# often argue that TypeScript is not a true statically typed language. This feature is optional for TS & eventually, it's transpiled into untyped JavaScript, which brings the risk of weird type conversions at runtime.
Even though it's relatively easy for JavaScript developers to learn TypeScript due to the similarities, you still need to invest time and effort in learning types and some TypeScript-specific constructs.
Enhanced code readability is a pro of TypeScript, but this can often result in bloated code due to a lot of type annotations and syntactic sugar. It also means .ts filetypes are often larger than their .js equivalents. Luckily, this is negated by the fact that once TypeScript is transpiled into plain JavaScript, the browser will only execute the JavaScript.

In the next post about TypeScript, I'll outline a bunch of common types that are used in TypeScript with some examples to help you with your TypeScript journey!

A data driven decision on Cross Platform Mobile development (Flutter VS React Native)

Hasib Ahmed — Sun, 23 Oct 2022 14:24:11 +0000

A little intro of me so you can see my motivations/reasons;

I want to create some side projects which are mobile apps, but I don't want to have to write native code for 2 platforms! I also would like the easiest & fastest developer experience & I need to make a decision on which framework to use, without procrastination by watching YouTube every time I need to start a project.

I'm a full stack consultant & developer, my usual day to day consists of JavaScript, TypeScript or Python. I've created full stack solutions with React on the front end, so my thinking is that React Native shouldn't be too much of a jump, right?

On the other hand, I've also used Flutter to develop an anonymous crowd sourced voting application for one of my university modules. I found the documentation quite easy to follow, & the Flutter community is even bigger now than it was back when I last made a Flutter application. I don't like to make a decision without some data insights, so let's pull data from Stack Overflow, GitHub and some job boards like Glassdoor.

For our first comparison, let's take a look at Google Trends for search results of Flutter vs React Native over the last 5 years:

Interest over time between Flutter (blue) and React Native (red).

Data from the Stack Overflow 2022 survey also shows Flutter in the lead (but just slightly!) when it came to the question "Which other frameworks and libraries have you done extensive development work in over the past year, and which do you want to work in over the next year?".

A snapshot of both Stack Overflow and GitHub data, taken late October 2022:

Data	Flutter	React Native
Stack Overflow Questions	143, 512	123, 937
GitHub Stars	146K	105K
GitHub Forks	23.6K	22.5K
GitHub Issues	11, 081 Open/63, 386 Closed	1943 Open/21, 406 Closed

Just using the data regarding number of Stack Overflow questions, you could come to the conclusion more questions means more problems/issues, or that there are more developers using this framework. Similarly you can say the exact same looking at the number of GitHub Issues for both Flutter and React Native.

A lot of people compare the speeds of both Flutter and React Native. React Native’s architecture requires bridge-based communication that enables interaction between JavaScript and the native user interface components and device-specific elements such as camera, Bluetooth, etc. Because of this, React Native is a bit slower than Flutter. Flutter doesn't rely on bridge-based communication instead it uses Skia, it's core graphic engine to compile the UI to device native code. Nevertheless, the small difference isn’t going to be noticeable in your everyday use case.

One final point is that Flutter provides a lot of "out the box" functionality, when compared to React Native that gives you a lot more flexibility to pick and chose what you use for UI, build, packaging etc.

For a new challenge & to be different, I'll go with the new rising star which seems to be Flutter. Whatever you chose, you won't be short of online material or useful third party libraries. One thing to note however, it seems as though there is more job roles that require React Native, most likely being that JavaScript is a much more ubiquitous language compared to Dart.

Blockchain layers — What are they?

Hasib Ahmed — Wed, 05 Oct 2022 13:08:01 +0000

After reading a little more about blockchain, I’ve come to the conclusion it’s pretty similar to an onion. Hear me out, it has layers, it’s smelly & makes you cry (probably but don’t quote me on the last two).

What are the layers and what does each one do?

The multiple layers of blockchain are broken down into;

Hardware/Infrastructure Layer
Data Layer
Network Layer
Consensus Layer
Application and Presentation Layer

Hardware/Infrastructure Layer

Somewhere in the world the blockchains content is stored & clients can request content or data from servers via the web and apps — this is called client-server architecture.

Clients can also connect with peers and share data — this is called a peer to peer (P2P) network, essentially a big group of computers that share data.

Blockchain is a peer to peer network, and each computer in this network is called a node. This network has a shared ledger which validates & records transactions. Due to the way peer to peer networks work, the data is distributed between nodes which creates a distributed database.

Data Layer

The data structure of blockchain consists of ordered transactions, which can be expressed as a linked list of blocks. A linked list is a list which chains together items within that list. Each item consists of pointers which reference the previous item in the list and data.

Blockchain transactions are digitally signed, which helps to protect the security and integrity of the data contained within the blockchain. The digital signature ensures unity, detects information manipulation and along with encryption of the data, any manipulation will render the digital signature invalid. The owner/sender’s identity is protected by a digital signature, therefore, a signature is legally associated to its owner and cannot be ignored.

Network Layer

The network layer is also known as the peer to peer layer or the propagation layer. Blockchains operate over a peer-to-peer network. Peers share information about the state of the network. Privacy and security is included in the network layer. It’s responsibilities include;

Inter-node communications
Discovery
Transactions
Block propagation

This layer makes sure that nodes can find & interact with each other and synchronise in order to keep the blockchain network in the correct state.

Consensus Layer

The consensus layer perhaps the most critical layer & is essential for blockchain platforms to exist. This layer validates the blocks, orders them and ensures everyone agrees.

Read more about consensus mechanisms here on Ethereum.org.

Application and Presentation Layer.

The application layer is made up of decentralised applications (Dapps), Decentralized Autonomous Organizations (DAO), chain code and smart contracts. The protocols in the application layer are subdivided into application and execution layers

The application layer hosts the programs that end users interact with to communicate on the blockchain network. User interfaces, scripts, frameworks and API’s are all a part of this layer.

The transactions will then move from the application layer to the execution layer to be validated and executed. The application will hand instructions over to the execution layer, which in turn will execute the transaction and ensures the deterministic behaviour of the blockchain.

Now hopefully you’ll agree with me in the fact blockchains are like onions, at least the layers part of it, and also have a (slightly) better understanding of what each blockchain layer is doing.

Getting into tech? Here’s your one stop shop as a beginner

Hasib Ahmed — Wed, 05 Oct 2022 12:55:13 +0000

So, you want to get into tech but don’t know where to start? Well, here’s my attempt at a one-stop-shop for newcomers, returners, career switchers alike! The tech sector is growing and doesn’t show any signs of slowing down, working in tech is fun, rewarding, exciting and fast-paced & the benefits include remote working (even before the pandemic), flexible hours in the majority of the companies & finally not to mention very well paid!

One of the hardest decisions is what career path to go down in tech since it's so vast. There are so many jobs out there like Front End, Back End, Mobile, Full Stack Engineer/Developer, Pen Tester, Cyber Security, Data Scientist and the list goes on.

If you're looking at non-coding jobs within the tech sector you're covered too! With jobs like Business Analyst, Product Manager, User Experience Designer and more. The notion of "you have to be good with computers to work in tech" is so outdated and not true for non-coding specific jobs.

During my time at university studying Software Engineering I was toeing the line between going for a developer, more coding focussed role or going towards a more business side, less technical role. So don't worry if it takes some time to really know what you're interested in! It takes time & research into all areas of technology, I would highly recommend initially starting on YouTube and searching around regarding tech in general to find out what draws you in more.

In this blog post, I'll address the coding jobs a little more & give some insight/tips on what I would learn if I had to start again to get a good grounding. You may not enjoy coding, but what I will lay out in this post is all free content that anyone can access and learn whenever it suits you best.

As I mentioned above, initially I would look to YouTube for general and even random knowledge about tech and the tech industry. This is key for increasing your knowledge and interest but also expanding your thoughts about what tech is, what industries it touches (you'd be surprised) and what you could potentially do with tech. Some personal recommendations on YouTubers I watch:

Forrest Knight, for general computer science/software engineering knowledge.
Andy Sterkowicz, a self-taught programmer himself who has very helpful videos regarding coding and becoming self-taught.
Joma Tech, makes funny skits about tech and coding in general.
Amigoscode, useful tips on what life is really like as a software engineer & various free tutorials & courses on programming.

The list is endless, start with these recommendations if you don't know where to begin and let the YouTube algorithm take over and suggest videos.

So, you've looked around on YouTube & you're still interested in a career in tech, maybe even more interested than you were previously. I hear you asking, what's next? That's a great question.

I think a basic description of the two main types of developers/engineers is important to bring up now, front end developers and back end developers. I will be massively oversimplifying it, but that's all we need to know for this post.

Front end developers are primarily responsible for everything you see on a web page/app. So the images, buttons, the fancy animations when you click on something, etc, is all the work of a front end developer. The average base salary of a Front End Developer in the United Kingdom is around £51,926 and the average for a Junior Front End Developer is £27,216, according to indeed.com.

Back end developers are primarily responsible for everything you can't see, but without it the app/web page wouldn't work. I like to think of it as the wiring behind the scenes to make the actions you do on a website/app work. One example of this is searching through Amazon for products, a back end developer would handle the work to make sure the right products come back for the term you searched for and you don't get results for "Wine and Cheese" when you search for "Work Party Items". The average base salary of a Back End Developer in the United Kingdom is around £58,218 and the average for a Junior Back End Developer is £30,388, according to indeed.com.

A fullstack developer is essentially both of those developers in one, a jack of all trades or you could call them a whole dev team in one person… Due to pretty much being able to do all and any development work required they're usually paid the highest. Fullstack developers usually dabble in DevOps work too.

Okay, bad political jokes aside, let's get into what we need to learn to get a good grounding for technical developer roles. If I was to start learning tech from scratch again, I would aim to learn how to become a fullstack developer. Just learning front end development will mean your app/website will look nice but not have much functionality & just learning back end development will mean your app/website will have loads of functionality but look quite bare. I chose this specific path due to the flexibility of being able to adapt to any task needed, also knowing the full lifecycle of developing something from start to finish & having the knowledge to do it all.

As someone new to tech, I would recommend starting with front end development initially. Specifically, web development and the reason for this is because it will help someone new to tech understand the process of software development and also to see code being turned into something visual. This helps a lot as you can see your code turning into titles, images, fancy transition effects and more as you're typing.

The resources I'd use for this are as follows, feel free to do any or all the things listed but they are generally in order & I would advise you read through them all before picking them up:

Google. Google will literally be your best friend, for anything you're stuck with & can't solve, any errors that might pop up, everything is a Google away. Even the most senior developers use Google on a daily basis so don't be shy!
Codecademy's HTML & CSS course. There is nothing to set up here as you will type code into your web browser & don't worry about the certificate which is only available with a subscription, we're here to learn as much as we can for free to start off with.
The Odin Project Foundations course which goes into more detail than the above Codecademy courses with things such as setting your development environment up on your machine, version control basics using Git and even getting into a decent amount of JavaScript (a widely used programming language). This will also go over some intro to the back end on what happens behind the scenes of a web server.
At any time, feel free to YouTube tutorials such as "how to make a website" or even "beginner website ideas".
Add to your online portfolio! Like designers, photographers or any other creative field - you are also creating things, just with code. You should use GitHub as it's the industry standard as a portfolio and code sharing platform, here is a very short introduction video to watch. Feel free to watch more videos if you want or need more information on this topic! This is a great way to showcase your work, upload your projects, websites and training notes onto so that potential employers to see the work you've done so far on your tech journey when you come to apply for jobs! Follow along with some tutorials and then try to make a couple of your own websites to add to your GitHub.

Once you've gone through all this post with the recommended learning & resources, you're well underway on your journey to a career in tech! By this point, you should have more of an idea on what you want to continue learning, what interests you in particular & if not, everything is a google or YouTube search away!

In future blog posts, I will go into other types of roles in development, including non-technical ones with as much as I can comment on them as well as how to apply to a job in tech.

University Group Projects — Tools & Tips To Ease The Process

Hasib Ahmed — Wed, 05 Oct 2022 12:38:32 +0000

Whether you’re a studying computer science/software engineering or you’re a student currently doing a project as part of a group you will know the frustrations when it comes to working with others. Having just graduated from university where I studied Software Engineering, I have had my share of experiences from working in a group. At times it feels like you’re the only one trying to complete the task at hand (and sometimes this is true!), however, I have some tips and tricks from my experiences working within groups during university and in industry as a software developer intern which should help you with your next group project.

Project Planning

Effective planning. Two words which seem simple enough when said but are rarely an occurrence during university group projects. By effective I mean, a clear outline of what needs to be done, an organised approach towards implementing the agreed tasks and some form of tracking tasks through their various phases. This along with documentation whilst on the project go a long way in organising the entire project and will help when it comes to writing the report (which is a common deliverable in university) at the end of the project.

A tool which helped me in this aspect is Trello, a free Kanban style list making web application where you create headings for lists and then each item is a card under that list. For example, for a group project in my final year here is some of the headers we used to simplify our project planning and to clearly see what tasks needed to be done, what we were stuck with, what was in progress and what has been completed.
Screenshot of Trello, including headers such as blockers, to do, in progress and completed/review

Implementing this in your next group project, whether that be a software project or a report, is as simple as signing up and spending 5 minutes creating headings for your lists. As the project progresses, you can add more and more tasks under each list and assign them to members of your group. Once the project is underway, it is easy to go back and see tasks in each state (to do, in progress or completed) and build a report/documentation without having to remember everything from when you first started the project.

Communication

We all know communication is important when it comes to working in a group in any setting, but do we always put this first? A lot of issues which arise as part of working in a group always start small; someone cannot make it to a group meeting because of prior commitments, a member of your group taking longer than expected on a particular task or even a lack of understanding of the overall project.

Many of these issues can be remedied with clear communication, let me give you an example. I had a group project in university where we had to develop a cross-platform mobile application. A member of my group was taking longer than expected on a software task, baring in mind that the language and framework we decided to use was brand new to us all. Instead of constantly asking if the task was complete, I ensured they had the support to complete the task, or the option to pass the task onto someone else and start on a different one. Not only does this limit confrontation, it also facilitates understanding and more of an ‘all for one’ spirit within the team.

This was after a year of working as a software developer intern therefore I had a little more experience in working within a group setting. So, had this been prior to my year in industry, I most likely would have just picked up the task on my own and completed it without asking anyone in my group, leading to a lack of communication and the possibility of the task being done twice.

Tools which helped me on the communication aspect of teamwork is Slack, a messaging platform, or even simpler WhatsApp group messaging. Whatever works best for your team, if you know each other a WhatsApp group may be more convenient or if you don’t know each other well Slack is a great alternative and you don’t need to exchange mobile numbers.

Some lessons to take away from this:

Facilitate understanding over judgement, especially in a new team.
Let your team play to their own strengths, rather than forcing them to pick up tasks they aren’t comfortable with.
Consider your team as a start-up, have a cross-functional team where there is a mix of skills within your group.

If you want to learn more about working well in a small group/company, and some more insights I highly recommend the book The Lean Startup by Eric Ries. Get the free audio book with an Audible trial, which you can cancel once you have your book!