Software is never designed in isolation. In my career I have never seen someone come into a meeting on a green field project with a clear vision, draw what it needs to be done and everyone agrees and development start the next day. That might be the case if you have done that type of project many times but not for something new.
Instead in a healthy environment engineers and architects get together, start with a number of simple proposals, discuss pros and cons of each and the discussion is built up from there. Some might play the devil’s advocate, some question things and some ride their egos.
This decision making process is similar to the Blackboard design pattern where a common base, the “blackboard”, is iteratively updated by a group knowledge sources.
Below are some tips to guide a technical design discussion so it’s beneficial to everyone:
Start the discussion early – The sooner you start the discussion the better. You have more time to think the big problems through. You will have more time for experiments.
Keep attendees small – There is no magic number but a meeting with more than 8-10 people will not be constructive specially if everyone wants to talk. Choose the right people who have the knowledge and authority to make a decision.
Start with the customer – Everything starts from why and how it’s going to benefit the customer. Always start from “why” then go to how.
Requirements and constraints – Everyone should be on the same page about requirements and constraints of the system. Make these things clear. Being fast is not a requirement but a response time of under 2 second for 95 percentile of requests between 9am to 10pm is a sound requirement. Not every requirement comes from the customer. Think of testability, performance, modularity, etc. early in design.
Present your idea – Let your proposal loose, keep it casual, aiming to spark discussion, and get feedback. No need for a presentation because it’s ripe and has a high chance of rejection or change. Discuss each idea thoroughly. If an idea is rejected, document why. Do not jump to another idea too quickly unless you have documented and understood pros and cons. If an application is slow due to using a particular library and devs suggest to use another library make sure they have tested the first library enough and the decision is based on facts and reliable test cases otherwise switching to another library is just a waste of time.
Do simple things first – When solving a big problem start simple. Do not try to solve all the problems in the world at once. Implement the simplest thing first, take it to production and iterate. Create phases and do simple things in initial phases. Do not budge when PM tells you that we only have one shot at it!
Question everything – As the design meeting organiser or architect one of your tasks is to question everything. This might seem intuitive and many people shy away from asking questions or simply asking why.
If you take away one thing from this article it’s this. Try the role of the “questioning guy” in the next meeting and see how it unfolds solutions.
If you are stuck on a hard problem do not forget the power of Six Thinking Hats method. It has saved me few times.
Step back, watch and manage – Once the meeting started you don’t have to be the sole speaker and decision maker. Give space to all, encourage people to share their thoughts and feedback. Allow them to draw on the whiteboard specially create an environment that junior or shy engineers can have a say. Stop people who talk too much and want to be the sole speaker. Ensure the discussion progresses towards coming up with a decision aligned with the goal of the meeting. Good meeting facilitation takes practice and needs authority. Stop unnecessary discussions and off-topics. Do not allow bully, loudness, arrogance and anger to dominate the meeting. Leave egos out of the meeting.
Use tools effectively – Covid-19 taught (hopefully) many organisations how to work from home and use tools such as online whiteboards, documents, etc. better. A design might be clear in your brain but that is not going to be the case for everyone. Draw it for the benefit of all people and share it after the meeting. A drawing with a bunch of boxes and arrows goes a long way.
Address disagreements – If some people disagree with something, hear the reasons. Know the difference between a technical reason and arrogance or reasoning out of ego. Make sure the disagreement and reasons behind it is discussed. Do not let disagreements linger undiscussed.
Finish with notes – Collect the key decisions made and write up the summary, circulating it to the meeting attendees. If you used a whiteboard, take a photo. Assuming there was an agreement, these notes might be the start of a design document. You may also want to keep a Decision Registrar. Do not forget the action items.
Do not drag the discussion – It’s best to make a decision late enough when you know more about the problem. The more you delay the decision-making the batter. This is called the last responsible moment. But delaying the decision making does not apply to everything. Do not drag decision making otherwise you will not achieve anything and there will be a lot of open items in your agenda.
The last responsible moment is a point in time when you must make a decision otherwise there will be dire consequences or it would be irresponsible not to.
Iterate – Depending on the type and complexity of project/problem you are tackling there is a high chance that you cannot cover all the items in one meeting. You will need multiple discussion meetings across your SDLC. Ideally more before dev starts, then a few during dev when you get real feedback and hopefully less during more formal test cycles and production.
Follow up and execute – This is the hardest part! Sometime after the meeting follow up on the action items. Also any discussion for the sake of it is just waste of time. Go to production asap. Demonstration defeats discussion!
Team architecture is one of the major concerns of any engineering group in tech companies. How do we arrange people in teams so that the best outcome is achieved.
Definition of a team usually makes sense in the context of ownership. What is it that a few people can own to form a team for? This is the first question you have to ask when forming a team. What they will own and what happens to the product when the team vanishes.
Another aspect that make a team more effective is the reporting lines, e.g. an infra team that does not report to engineering but reports to the operations is just waste of their potential. This is a different topic I will get to later.
Below are some thoughts on the subject (with focus on software products) that will hopefully spark more thinking and discussions.
Patterns of Team Structure
The definition of the following patterns is not rigid at all. They have a lot of overlap, similarities and some even come under hierarchies. Some teams have different names in different organisation. A DevOps team in one company might be the Infra team in another company. I haven’t made much effort to classify them into a better grouping or structure.
In reality we group teams together all the time, e.g. CloudOps consist of cloud team, DevOps team and operations team; or a commerce team may consist of billing team, ordering team, etc. Teams similar to software can have levels of abstraction and hierarchy.
These patterns provide tools to ask questions on why the teams are formed the way they have and if there is a better way to re-structure them.
An organization may have one or more products, e.g. Kayo, Binge, etc. Products my be for internal or external customers, B2B, B2C, etc.
This pattern has some variations:
External customer: Product may be developed for an external customer. If the external customer has very tight timeline and budget constraints the long term support of the the products may face difficulties.
Internal customer: Product may be developed for an internal customer. The company owns the product and the team has a better sense of ownership. Internal products usually receive more care and longer term support. Internal products may be a revenue generating product such as Kayo for Foxtel or an internally used productivity or cost saving product such as bedrock vending machine.
Bundle of products: A team that works on a group of products.
Product variation: A team that supports a variation on a product, e.g. Android team, iOS team.
For a product team to be successful they have to be cross-functional and own all of product + design + engineering. Product team’s goal should be solely customer focused.
A team that supports or owns a feature or a process within a product. A feature team is usually across multiple domains or applications. When a process/feature/journey/aspect is big enough then it requires a team to handle it.
Example: signup team, purchase flow team, user journey team, search team, etc.
Feature teams usually have many communication points as they interact with many other teams and applications.
Processes may have sub processes and that might mean sub-process/feature teams.
Feature team may be a short lived team and has similarities with project teams below.
Teams by Conway’s Effect
Conways law states that the communication structure of an organisation influences the systems they build. That means they architecture of a system is affected by the team structure.
The effect of team structure on system architecture makes team building an architectural concern not a management or agile activity.
As a rule of thumb remember the Reverse Conway which focuses on a team structure that matches the desired architecture we want.
If the architecture of the system and the architecture of the organisation, are at odds, the architecture of the organisation wins. Ruth Malan
It’s a famous model you can read about here. Since Spotify announced this model it was adopted by many organisations some of which took it too seriously unlike the Spotify themselves (according to Kingberg and Ivarsson on the original Spotify blog they partly implemented the model!)
One major problem with the model is that there is no regards to the team size. You have to be careful otherwise the tribes will grow too big.
One important measure for a team size is team cognitive load which is the amount data, information, task and process a team is capable of handling. This imposes constraints on the software architecture too because there will be limits to the amount of components you can realistically place into an architecture that a team is responsible for.
Sometimes too many bugs in a system is an indication that the system is bigger than the cognitive load of the team and the team is having difficulty figuring things out.
Spotify model also doesn’t talk about the dynamic interaction of teams; it’s static.
A platform team in digital companies is a basis that provides self service APIs and reusable tools to other teams to perform their duties. Example is DevOps team that builds CI/CD pipelines, application templates, etc.
Platform team nowadays is a capability that gives companies an edge. As a rule of thump if a reusable thing finds more than 3 users, then it may be time to consider this a horizontal responsibility and move it to a separate team.
If a reusable thing finds more than 3 users, then it may be time to consider this a horizontal responsibility and move it to a separate team
On the other hand, if the platform team is not self service and automated enough it will eventually burn the team or grow it unmanageably large. It is just pulled in all directions by many teams. Self sufficient teams that have a member from the platform team (capability) take this direct pressure off the platform team. Ideally other teams should contribute seriously to the platform and the platform itself should be flexible and extensible to allow such contributions.
The concept of platform team paves the way to define capability teams. Teams that are specialised and take care of an speciality across the organisation such as Kubernetes team, Identity team, etc.
Some do not like the idea of DevOps team and would insist on merging Ops and Dev and define DevOps as only the concept of affinity between the two but I doubt this is true anymore. Nowadays DevOps is an abstraction layer on Ops teams where they stay on their hardware/network/storage realm and DevOps take care of the necessity for more automation, container orchestration, GitOps, CI/CD, etc. More on the later.
A team that is formed for a project. These teams are usually short lived depending on the nature of project. Project teams usually have the role of project manager. Care has to be taken for the long term support, maintenance, ownership and upgrade of the created product or service when the project finishes.
As project teams are formed every time for a new project, they share the common problems of a new team such as personality clashes, etc.
Project teams are usually more constrained with time and budget. From personal experience showing a project plan or timeline to developers just makes them miserable! Just shield them from it as much as possible!
A team that is responsible for a component (part) of a product or feature. This could be a considered as a variant of a product team as well. Component teams of function best as cross functional teams.
Example: backend team, front end team, watchlist team.
Even though a component might be a feature and vice versa but component team focusing on one well defined part of a system is usually the opposite of feature team working across many components.
If you have defined boundaries for each domain in your business context you can have domain teams, e.g. commerce team, content team, billing team.
Domain teams usually map to the capabilities of a business. A business with capabilities such as sales, marketing, streaming may have teams with the same names.
Each domain may have a manager and/or architect. Domains are hierarchical in nature hence this pattern has a logical variation of sub-domain team.
Cross Functional Team
This type of team has at least one member for any capability they need to make them self sufficient and to reduce cross team communication and dependency. It is also called self-sufficient team. These teams seem to be high performing teams due to less external communications and better internal communication (cohesion).
One problem with this type of team is that they might diverge from the standard architecture of the overall system that organisation follows and there should be ways to align and enforce such standards, e.g. using a self service platform.
HBR says that 75% of cross functional teams are dysfunctional. Read here why.
If cross-functional team is a thing then we should have a definition for a functional team as well. A functional team is responsible for or corresponds to a function unit or domain of an organisation.
A functional team has a lot of similarities with domain team and component team, e.g. accounting team, IT team, platform team, development team, billing team, test team, architecture team, call centre team may all be called functional team.
Specialised teams that build or maintain a piece of technology or a group of technologies. Example: Kubernetes team, front end team, backend team, UX team, Java team, etc. These teams are not self sufficient and many depend on them. They also usually do not map directly to an organisational value stream.
Consulting (Enabling) Team
Specialised team that is formed internally or hired externally for specific purposes, i.e. something that organisation has no knowledge of or does not want to spend time on. Example: cloud migration team. This type of team usually has a short life span and require close management to make the best out of it.
Outsource and Offshore Team
Many businesses nowadays outsource part of their workloads to onshore or offshore teams. Common problems include: culture differences, timezone differences and lack of present management. You organisation also loses the knowledge of that team when their contract finishes.
This form of organisations are a combination of functional and project teams. An individual works in a project/product team and at the same time part of another functional/domain team, e.g. an architect is part of the architecture team and also works on a project.
Matrix organisations or teams is an old concept and is the basis for the Spotify model.
A team that is formed for a short period of time in order to handle a time bound task. Care must be taken in terms of the ownership of end product once the temporary team ceases existence. Examples are project teams or task force teams. They have a limited life span.
Team Dependency Patterns
Teams depend on each other for different reasons. This is where team boundaries have to be defined and as said above as part of Conway’s Effect, the team boundary should ideally be dictated by system architecture.
Knowledge dependency: A team needs the knowledge of another team e.g. the billing team needs the DevOps team to setup CI/CD pipeline for them.
Task dependency: A team’s output is another team’s input, e.g. a team is waiting for an API to be ready for consumption.
Decision dependencies: A team’s decision affects the tasks of another team. Example: the way front end team wants to consume APIs will affect how backend team creates those APIs in terms of technology and granularity.
Team Communication Patterns
The teams communicate in many different ways. Remember that teams are made up of people and even though with teams we create boundaries but people are still free to talk to each other and this opens unlimited communication paths.
Ideally we want less communication across teams (low dependency) and more communication within the team (high cohesion).
Formal communication – collaboration based on their org structure, reporting lines and formal team boundaries and communication tools (chat, email, etc.) This type of comms usually include hand offs.
Informal communication – collaboration based on interpersonal and friendship relationships or how people influence each other beyond the formal titles and org charts in a personal level. Even though this sounds cheesy but a lot of tasks in organisations are actually performed via informal interactions. Sometimes this is an indication of wrong team boundaries, missing capability in the team or incorrect org charts (people are not where they should be)
Communication by Service – based on services provided by another team. A team provides a service (e.g. payroll or platform) and another consumes
Communication by API – based on an API provided by another team.
Benefit of communication by service or API is reduced human interactions or hand offs.
It is always fun to have a local Kubernetes to try new things on but there are a few different options with varying capabilities that might look confusing at first.
Some of the following products are also useful for setting up a home lab, home server or even production grade IoT.
In this short summary which is basically a copy-paste of my personal notes, we look at different options that will help developers work with local Kubernetes clusters.
This is obviously ignoring cloud providers. If you have access to a cloud provider they all now provide k8s as service or you can set it up yourself on their VMs.
Disclaimer: These tools evolve too fast hence the validity of this material might be short but I try to keep it up to date!
Kind– Started in 2019, Kind is a mini Kubernetes on Docker by the Kubernertes developers. The cluster is basically a docker container running on docker runtime
Pros: Very fast startup
Cons: high memory usage, not a fully compliant Kubernetes
MultiNode: yes – 1 master
Min Memory: 8 GB
K3s and K3d– Lightweight, fully compliant ks8 which is best for IoT, ARM and edge developed by Rancher. k3d is a lightweight wrapper to run k3s in docker.
Pros: fully compliant, production grade, very light
Cons: Not on Windows yet
Min Memory: 100 MB
Docker Desktop – If you use Docker desktop on Mac or Windows you get a k8s cluster for free. It runs on docker.
Pros: Images are readily available, comes as part of docker desktop
Cons: high memory usage
Min Memory: 4 GB
Minikube – Mini k8s by the Kubernetes developers that can run on a VM (e.g. VirtualBox) or even docker. It started as early as k8s itself around 2012.
Pros: Simplicity, add-on based for adding extra functionality as needed e.g. loadbalancer
Cons: Running on VM is slow
Min Memory: 2GB
MicroK8s – Fully compliant k8s by Canonical (Ubuntu folks) that is supported on ARM, Windows, Mac, etc. It was previously only available with Snap package manager but it has improved much. It’s lightweight and great for IoT similar to K3s. It also supports a number of extension add-ons similar to Minikube.
Pros: Runs on any platform, production grade, has extensions
Cons: On Windows/Mac need a VM
Min Memory: 4GB
FireKube – This is opensource by Weave that runs on VMs. Haven’t tried yet!
If you want to setup a multi node clusters in a home server you would need VMs and this discussion will not be complete if we don’t talk about different ways of spinning VMs.
This is in my order of preference:
LXD, LXC – This is the fun one. Runs only on linux but it’s the fastest and lightest approach since it uses userspace concept of linux. All VMs share the same kernel as host though. LXC/D runs the full OS system and provides an environment similar to a VM but docker runs an application process in a container.
Multipass – By Canonical, runs on any platform, good startup time, nice command line. On Windows/Mac needs a hypervisor such as Vbox or hyper-v or even docker which is faster.
Vagrant – By HashiCorp, runs on any platform, ok startup time, good command line. Needs a hypervisor such as hyper-v, vbox or docker (faster)
Virtualbox/Parallel – Simple to use, UI based, command line sucks. Need to tweak for best memory usage, etc.
I have been taking notes since I remember. We all write to keep things for later, gather and keep information, remember and remind things, catalogue our thoughts, etc. Everyone has their own style or reason for taking notes.
I also use notes as my short term and long term memory as my biological one is a bit faulty!
I take notes on the latest books or articles I read, how to do things at work, processes, discussions with people, how-to’s, project notes, meeting notes, tasks lists, todo items, etc.
Many years ago when I started taking notes seriously it was all on Evernote. After a few years I moved to the shiny OneNote as it had more features and better abstractions for organisation (folders, notebook, sub page, etc.). Recently I even used to write hand written notes on my tablet with a pen. It has served my well but I wasn’t entirely happy! No particular environment or program is best for any one person.
One weekend with the help of some buggy VB script I converted most of my notes from OneNote to plain text. BOOM! You might be asking why?
I have to stress that this subject is highly preferential. Every one’s style and needs of note taking and expectation of tools is different. Plain text is not for everyone.
Why plain text
I get distracted on busy, mixed formatted text with colours, multiple fonts, menus and different options! I also want full control over my notes (where they are, how they look, what structure, what format, etc.)
Nothing can beat its simplicity in terms of aesthetic and structure of your choice (main reason)
It’s not limited to any text editor or tool. You choose your tool or change tools easily. You can read and edit on a shiny MacBook pro as well as Windows 98 VM or command line. They all show the same thing. (second reason)
Plain text is flexible. You can convert it to any format you want. You can apply formatting to it as you want: Markdown, asciiDoc, reStructured, etc. but still the raw content is yours.
It’s fully searchable. I hated search function of OneNote! I can even search faster in command line.
As developers we deal with plain text all the time in code, in command line and everywhere so why not note taking?! You can version control as well 😀
Full control of where notes sit (which note provider or cloud server or version control)
Now that all the notes are in plain text I can organise them in folders, some that are more important or permanent become Markdown otherwise it stays .txt. Images have their own folders. For now everything is in a Github private repo and I use VSCode with a bunch of command line aliases for quick access to certain notes and searches (you can also auto commit if you want but I do not)
For plain text or Markdown you probably still can use EverNote and there are many many other options such as SimpleNote, iAWriter, Notion or native apps in different platforms (e.g. Apple Notes) but the above simpler approach keeps me happy for now.
P.S I still use Google Keep for quick notes when not behind a laptop.
Some companies allow employees to work from home. Working from home is based on trust. The employer trusts employees that they are still working while not in office and still proactively move projects forward no matter what. Below are just some random thoughts on how to improve the way you could work from home.
Let your team know you’re remote
Tell your manager beforehand or/and put it in a relevant Slack channel that you will be remote.
Mention times that you might not be available and set into your Slack or messenger when you’ll be back at your desk. Be clear about the times of the day you are (not) available. Don’t forget to take leave for your unavailable hours.
Use video chat
You will mostly be in touch with your colleagues through text messaging but don’t underestimate the power of video to convey your meaning. Only use video when you have exhausted other ways of communication. Also use the power of screen sharing.
Attend stand-ups and meetings
Attend your scheduled meetings and stand-ups. Let people know what you are doing. Keep in the loop.
Let people know what you will be working on that day through Slack or other means. Someone from you team might benefit from that.
Don’t forget to go on mute if you’re not talking.
Pay attention to your writing
When you are working remotely, what you write is what you mean. People actually judge you by your style of writing. Before hitting Enter proofread your sentence. Is it correct in terms of grammar and spelling?
In Slack you can actually go back and edit but an email sent, is gone. In Jira, Confluence and Slack use proper text formatting syntax or Markup. Do not just copy-paste text into these systems. This is more important when you paste code or scripts. If you are careless about your writing I assume you are careless about the work you’re producing.
Make sure you have a proper desk, chair, and monitor at home. Your have already tested your VPN access, have a reliable Internet and most importantly a quality headset.
Using a headset is better than your laptop’s mic/speaker and will not generate echo.
If a system is not accessible remotely speak up. Raise an IT ticket or tell someone about it.
Focus might be a big issue when working in office and it could be one of the reasons you might want to WFH, to have less distractions. Perhaps you want to focus on something particular like a delivery or a document.
But at the same time you might have other distractions at home such as family, Facebook, phone, TV and your bed.
Unlike when you’re in the office when you’re at home nobody is seeing you hence there might be a tendency to slack off. You can work in slots of 1 hour work and have a break.
You’re expected to perform your tasks regardless of where you are. If you have a good manager he or she will not care where you are as long as you finish your tasks. Being accountable for what is expected from you is also called integrity. It is doing the right thing when nobody is looking. Be proactive and finish your tasks and follow them up. Do not assume your job is done and it’s now with someone else. If it relates to you, follow it up till end. You do not need someone to babysit you.
Working from home is not a replacement for carers leave. If your children are sick or have 20 guests or you need to mow your lawn then do not call it working from home. Just take the day off or take carer’s leave.
In the past few months I moved from Huawei Watch 2 4G to Samsung Gear S3 Frontier.
Huawei is a well designed and tough looking Android Wear watch. I don’t have anything against the design of the watch. It is well made, lightweight and packed with sensors. It also has a 4G version that accepts sim cards. The default strap is nice and grips very well.
The only issue I have with the watch is Android Wear operating system itself! It was slow and lagging. Not responsive. I have seen the lag in almost all of Android Wear watches. This is an inherent issue with Android Wear.
Samsung Gear S3 Frontier
On the other hand Tizen on Samsung Gear S3 Frontier was snappy. I have had it for a week now and haven’t noticed any lag or delay in response.
This is a bigger watch and heavier. Being bigger is a positive point for me as I’m getting old and struggle with small fonts! I especially like the rotating bezel as it gives a great tool to move around instead of pressing a tiny button or swipe screen. I find the bezel a game changer in the design of smart watches and a huge plus point for Frontier.
Looking forward to the next version in 2018 and I hope they keep the bezel.
I obtained 5 certificates and cleared 6 exams in 2017, AWS solution architect, developer and SysOps in associate level, Scrum Master and TOGAF (part 1 and 2).
It has been quite an achievement personally, taking into account a full time job and family with two little monsters.
I have written already about AWS exams but for TOGAF I studied about 3-4 months, 5 hours a week roughly. It’s a very dry subject and requires a lot of memorisation. I might write about pros and cons of TOGAF as a framework in general later but I would suggest everyone who calls themselves an architect in the IT world take this certificate. A Udemy course on the subject was also helpful.
With any certificates you have to memorise a lot to pass the exam; it’s not just about knowing or understanding the subject. This is the part I have problems with and the reason behind not having any certificates after working in IT for many years! This year I thought I will give it a try for a change!
In order to pass a certification exam and truly understand a subject you have to find the right balance between memorising concepts and learning them by heart. This is very important otherwise you get certified and never understand the subject matter in detail. Your certification will just become a worthless piece of paper.
I am sure you have used your credit cards for online shopping, you enter the card number and click submit. Some of you might even have a Paypal account in which you use your email to make a payment. Your Paypal account is again linked to your credit card or bank account.
There is still a centralised governance which is the bank. Every transaction goes through the banks. There is a central “ledger”. We “trust” the credit card company to keep the transaction and our details safe.
In 2008 an article was published by someone called Satoshi Nakamoto and Bitcoin was born. He/she/they proposed a relatively new system of currency and implemented that into a software system and then we heard nothing from them after 2010. They just vanished.
Bitcoin is a digital, de-centralised currency. What does that mean?
Well it’s digital so there is no physical money involved, and it’s de-centralised which means no bank or governing body controls it and it’s managed by those who use it. Nobody owns the Bitcoin network much like no one owns the Internet.
Instead of a bank recording transactions in a centralised ledger, all Bitcoin users keep the same copy of the same ledger; as a result it would be extremely hard to mess with the system because everyone has to be in sync.
This public ledger contains every transaction ever processed in the system and every user has a copy of that. It’s an example of triple entry bookkeeping system.
But how Bitcoin is generated?
Unlike real money that is usually backed by gold, Bitcoin is backed by supply and demand and is created using a process called “mining”. This is an analogy to gold mining in which you do work and get rewarded with gold.
Mining is the process of spending “computing power” to process transactions, secure the network, and keep everyone in the system synchronized together. Bitcoin mining provides a reward in exchange for useful services required to operate a secure payment network. Anybody can become a Bitcoin miner by installing the correct software version.
So what’s Bitcoin good for? The following are some of the benefits of Bitcoin:
Cheaper to transfer money as it goes directly to another person
It can work across the globe. Not tied to a government or country
No currency conversion
Not affected by currency fluctuations
It has been designed to have a limited number of bitcoins (maximum 21 million) so there will be no inflation
From a user perspective, Bitcoin is nothing more than a mobile app that provides a personal Bitcoin wallet and allows a user to send and receive bitcoins with them. This is how Bitcoin works for most users.
There are different ways to obtain bitcoin:
Sell products and accept Bitcoin
Buy Bitcoin directly from Ebay
But Bitcoin is not without problems. Let’s look at some of its problems:
Degree of acceptance – Many people are still unaware of Bitcoin. The number of businesses using Bitcoin are very small compared to what it could be
Volatility – The total value of bitcoin vacillates a lot. The price went from zero in 2010 to 5600 USD few days ago
Still new and under development
Some have profited from being involved early – unfair advantage
It is legal at least in Australia as long as you declare your profit to ATO but it’s a perfect tool for criminals since it doesn’t need to be tied to a person. But it has been used in criminal activities as much as credit cards have been used
Some people say bitcoin is the 21st century version of gold without storage costs. Some people call it a fad, hype or even fraud.
Bitcoin is a big deal in computer world and in ecommerce; everyone is jumping into it and it’s growing. But will it ever become a major payment network? If we could get bitcoin to work or something like it, if we could trust a digital currency, it has a lot of potentials to transform our economy for better.
In the meantime I urge you to try it for yourself. Go ahead and install the bitcoin app, create your wallet or watch some Youtube videos about it. You can even buy some bitcoin from Ebay and see how it works.
When I was around 6 or 7 years old I wanted to become a pilot. Some kids want to become doctors, firefighter or…
Are we programming our kids from early ages that they have to work? Or it’s something intrinsic to human psyche?
Scientists have tracked bartering to 40,000 years ago; that is making direct deals between two parties of desirable objects. Those days people only worked to stay safe, feed themselves, survive or to have companionship. The concept of currency and money came a bit later around 2000 BC.
But why do we work? Why we have to work? And a better question might be, are we working for the right reasons?
Most of us work for money. Working for money has a bit of negative connotation to it but does it matter?!
Many people work for money to live comfortably. In the modern civilisation we have progressed to higher needs; we no longer only work to feed ourselves or to have a shelter but to live comfortably. Although there are still many people in Africa and other places dying of hunger but we try to ignore them unfortunately.
Many people work for money because they are forced to work in order to pay back their debts. We live in a debt based system. Humans are the only species that pay to live on the earth! When we are born we do not get a share of land by default. We have to buy it from the governments for some reason.
Many people work for money in order to increase their social status. It gives them identity. We pay ridiculous amounts of money to universities in order to have them stamp us with a seal of approval for work. Housewives may find it difficult to confirm their value in the society, no matter how much their work is appreciated within the family.
Many people work for money to gain freedom. My wife has gone back to workforce after caring for our kids for 4 years and she is happier than ever. She has financial freedom, and more socially engaged.
But sometimes work becomes the dominant force in our lives; it’s not a shortage of income that shackles us, but a shortage of time.
Apart from money is there a better reason to be working? Is money the core of why we do it? Is there a reason to be working other than money?
Fulfilment is a combination of accomplishment and purpose. Once we met our basic needs we move on to more exclusive psychological needs.
We might work to become an expert in a subject, discover our talents. It gives us pride.
We might work to do what we love and enjoy. Some people lose themselves in their work. Artists and scientists for example.
But according to a massive report published in 2013 by Gallup, more than 50% of american workers are dis-engaged or suffer from work related physical and psychological illnesses, so sometimes work is a shackle and a burden.
We might work to create a positive impact, to make other people’s lives better or make them happy or serve people.
We might believe in spiritual views of work. Embracing the notion that each of us is unique, precious, and possess something different and here to do something special.
So there are other reasons except money that might wake us up in the morning.
What about the future? What is the future of work? Will technology enable us to work from home or remotely all the time? What will happen to our social side then? Will robots take most of our jobs in 20 year as predicted by experts?
What do we do then?
For now just remember that we are here to live not to work.
I always loved running. My little 5 year old Kian also loves running. I think we get a great sense of self satisfaction when we run!
Three years ago I was preparing for 14k City2surf. Although a bit overweight at around 93 kg but I was able to finish 7k.
June 2nd 2014 was my first day at a new job. I was starting at Cubic Transportation Systems as a senior developer. On the way to work I had a little bike accident and torn a ligament on right knee. There is nothing worst that could possibly happen on your first day at work!
The whole dream of running was gone up in the smoke. I had to undergo a surgery and go through physio, etc…
Early 2017, three years after the accident I decided to give it a try again. Went on a diet, lost around 10 kg and managed to run my first City2surf in 1 hour 25 minutes with pace 6:09. I had to stop for a toilet break and lost a good 2-3 minutes but overall not a bad result for a person like me who was suffering from laziness and some extra baggage since I remember!
I have been on numerous diets, tried many methods but was never able to lose any weight. I was carrying extra weight since maybe 2004 after uni graduation!
Having a goal such as this race was the only motivation/stimulation that could force me eat less and healthy. I track my diet through MyfitnessPal and running through Runkeeper.