Category: Uncategorized

Examfly Certificate of Efficacy

Examfly has been awarded the Efficacy Bronze by EduEvidence – The International Certification of Evidence of Impact in Education (ICEIE) 🎉🏅

This independent, evidence-based quality mark is awarded by researchers at ICEIE and recognises the efficacy of Examfly’s learning approach – helping learners improve exam readiness, build confidence, and gain the knowledge to progress in their careers 💼.

The Efficacy Bronze is the first milestone in a progressive certification pathway, and we’re committed to achieving the next levels as we continue this journey – proud to be among the first EdTech companies in Ireland to do so.

For us at Examfly, it’s both a validation that our work is having a measurable impact and a motivation to keep raising the bar.

Onwards and upwards… 🙌💫

How We Use Bloom’s Taxonomy to Make Learning Stick


At Examfly.com, we design learning interactions with Bloom’s Taxonomy at the core – a proven framework that guides learners from basic recall to deep understanding, critical thinking, and real-world application.

Here’s how we map our tools to different levels of Bloom’s:

⸻

📘 Remember / Understand

🎞️ Animated Explainer Videos
Break down complex ideas using dual coding (visual + verbal) and chunking (manageable content blocks) making learning easier to process and retain.

✅ Multiple Choice Quizzes (MCQs)
Reinforce foundational knowledge through retrieval practice, strengthening memory and improving long-term recall.

⸻

🛠️ Apply

We design interactive tools that help learners transfer knowledge into action including:

🧩 Drag & Drop Bucket Games
Apply classification rules by sorting items into the correct buckets – fast, fun, and cognitively engaging.

📜 Paragraph Fill-in-the-Blanks
Apply knowledge in realistic sentence-level contexts, ensuring understanding beyond keywords.

🎰 Fruit Machine Scenario Game
Spin to receive a unique set of conditions, then answer context-based questions. This randomised challenge builds adaptability and real-world readiness.

⸻

🔍 Analyse

🧮 Double Entry Bookkeeping Games
Learners are presented with a Balance Sheet and Profit & Loss statement. They evaluate the effect of a transaction and determine where it belongs reinforcing an understanding of how real-world events flow through the financial statements via double entry logic.

🧾 Legislative Interpretation Game
Learners review real sections of tax legislation, answer interpretation questions, and highlight the specific clause that supports their answer — building skills in legal reasoning, precision, and evidence-based justification.

⸻

💡 Evaluate / Create

📝 Case Study-Based Free Text Entry (coming soon)
Simulate real-world scenarios that require constructing responses, justifying decisions, and thinking critically – perfect for reaching Bloom’s highest cognitive levels.

⸻

🌟 Why It Matters

By aligning every interaction with a clear cognitive goal, we make sure learning isn’t just engaging – it’s transformative.

Our goal?
To help learners think, not just click.

⸻
Are you designing your learning content with Bloom’s in mind?
Would love to hear how others are using Bloom’s to drive deeper learning.

hashtag#learningdesign hashtag#instructionaldesign hashtag#edtech hashtag#bloomstaxonomy hashtag#lnd hashtag#examfly

⸻

Image: Bloom’s Revised Taxonomy via Wikimedia Commons, licensed under CC BY-SA 4.0.

⸻

Deciding what to do next?

You lead a product engineering team. How do you decide what work to do next?

▶️ Whatever the customer asks for or may want.

▶️ What the boss wants

▶️ Prioritise the Highest Paid Person’s Opinion (HiPPO)

▶️ Choose the feature based on an estimate of the potential revenue generated?

▶️ Work required to meet legal and regulation requirements

▶️ Whatever ‘feels right’. Just because.

▶️ Follow your gut. Your instinct.

▶️ Tech Debt.

▶️ The ‘ilities’. The non-functional requirements. Work required to meet performance, scalability, security, resilience, availability etc.

▶️ The low hanging fruit.

▶️ The bugs.

▶️ The feature which will get you the experience you want to show off on your CV.

▶️ The largest impact on your key metrics.

▶️ Whatever your OKRs dictate.

▶️ Whatever feature has been sized and fits neatly into the remaining sprint.

▶️ Weighted Shortest Job First (WSJF)

▶️ Copy the competitors. Competitor Analysis.

▶️ A feature that appeared in a dream.

▶️ Whatever the sprint team decides is the next priority.

▶️ The loudest voice in the room.

▶️ The census ‘priority feature’ voted by the committee.

▶️ The feature pushed by the most passionate voice in the room. ‘I PERSONALLY believe …..’

▶️ Who cares about business priorities? That’s the Product Owners problem. I just code.

▶️ The most senior voice in the room.

▶️ The next item on the list.

▶️ The feature that you believe will most move the company towards the vision and aligned with the company goals.

▶️ Prioritise potential features based on a combination of estimated value and cost of development.

▶️ Taking bets on features and learning from users how they performed. Data driven decisions.

▶️ Bike shedding. Let’s prioritise what’s easiest.

How about you?

Will be interesting to hear how other software development managers handle prioritisation.

How do you do it?

How to Prevent Over-engineering a Startup

Over-engineering can cripple your startup. 

Here are 13 ways you can prevent this from happening.

If you are a technical solo founder or an all technical founding team you may need to read this.

Example Scenario:

Early stage startup. Tech solo founder or all technical founders. Pre PMF, little to no revenue yet. 

Got an idea to ‘change an industry’ and seeking to validate that through learning from user engagement & feedback. Fully prepared to pivot as you learn more.

1: The Golden Rule

Avoid premature tech optimisation. For example: Building to handle millions of users when your goal is 100s users. 

The software architecture that Netflix or AirBnB have in-place now was NOT their architecture when they started out.

2: The right software architecture depends on the context

Choosing the wrong software architecture will slow down your development velocity and increase your infra spend.

3:  Focus on what matters

Define your core business metrics.  EG AARRR or others. 

What metrics can ensure your business survives? Not just survive but thrive. The needles you must move. 

Focus your activity towards moving these needles.

4:  Figure out what the hard part is

Ensure the bulk of the teams effort is focused on the hard part. As a technical founder this may not be the tech. Often for you the tech will be the ‘fun part’. 

Make sure you prioritise.  Up skill and / or hire to fill the gaps.

5: Avoid Magpie Syndrome or Shiny Object Syndrome

What Tech stack should you choose? What you are most productive with is usually the right answer. 

Learning new tech comes at a cost of time. What is the best possible use of the time?

6: Marketing

If you think this is a dirty word you are in trouble. 

If you don’t have marketing skills on your team then you are all the marketers now.

Congrats.

 Same goes for sales.  Upskill and / or hire to fill the gaps.

7: Fight the urge to over complicate

Leverage boilerplate or template applications, no-code, PaaS options to avoid reinventing wheels. Free up your energy to focus on what really matters to your startup.  See number 3 above.

8: Avoid EGO driven development 

When you make tech decisions based on what tech you want to show on your CV.  This is EGO driven development. 

This isn’t about you. It’s a race to tap into an opportunity. 

9: If you build it…..

Developers love to build product. But building a product is a sub set of building a startup. How will you deal with managing what you need to do versus what you love to do?

10: Seek Advice

Most importantly. Seek advice from those who have been in the trenches. Such as a startup eco system. They can help you see your blind spots.

11: Embrace tech debt is a lever

Controversial. Paying off tech debt fully is for startups with validation, revenue, funding.

Take on tech debt and pay back when you can.

Better yet practise KISS, YAGNI, Clean Code to keep tech debt to a minimum

Have you earned ‘earned the right’ to deal with it?.  Leverage debt and pay it off when you can afford to.  If you get to that point. Congrats! 

90% of startups don’t make it.

12:  KIS. YAGNI

Keep it simple. You Aren’t Gonna Need It

Tip: Daily mantra to be repeated at every team standup.

13: Problem V Solution

Problem space versus solution space.

Depending on the startup stage you are at, the weight of importance slides between ‘problem space’ and ‘solution space’.

As devs we have a urge to skip the more ambiguous first (problem space) and instead jump straight into the second (solution space).

But the solution doesn’t matter if you are solving a problem no one cares about.

And how about you? How do you prevent over-engineering a startup? 

AI Developer Assistants 2023

GitHub Copilot is so last year. 

Here are 5 cutting edge emerging AI Developer Tools in 2023 to supercharge your productivity. 

1) Cody from Sourcegraph

Chat and instruct your codebase, ask nicely to write Unit Tests 

https://about.sourcegraph.com/cody

2) CodeComplete

YCombinator backed, private beta CodeComplete AI

Self hosted, fine tuned to your codebase.

https://codecomplete.ai/

3) FauxPilot – an open-source alternative to GitHub Copilot server

https://github.com/fauxpilot/fauxpilot

4) Tabby

Open-source and Self-hosted AI coding assistant

https://github.com/TabbyML/tabby

5) Copilot X

Next level GitHub Copilot with code chat, terminal interfaces, Github pull request and workflow integration. Currently in Preview

https://github.com/features/preview/copilot-x

All these provide alternatives to the existing popular tools including: Tabnine, Replit Ghostwriter, Amazon CodeWhisper, Codeium. 

Ok thanks for reading. 

This is an exciting and rapidly changing space. 

Stay tuned!

Are you ready to adopt microservice architecture? 

10 reasons you are not ready for microservices👇🏻

1. When you consider microservices to be THE solution regardless of the problem.

2. When you think a microservice architecture is just what you need for your indie hacker side project currently with no users, pre-revenue and seeking product market fit.

3. You think microservices will ‘make things faster’.

4. If you think a mircoservice architecture is ‘simpler’.

5. When you have an IT operations team focused on preventing change from upsetting the smooth running of the system and a development team whose sole purpose is changing the system. HINT: combine them via devops

6. When the deployment of a new server into production is a painstaking and manual task of provisioning, updating and patching.

7. When you don’t consider how team topologies affects the architecture and architecture affects the team topology.

8. When you think a ‘monolith’ architecture is a ‘bad thing’. Why? Just because…

9. When your deployment process is painful involving multiple handoffs, approvals, signoffs and you don’t have a simple repeatable auditable deployment process. Microservices mean more deployments compounding the problem.

10. When you are manually handling server configuration, software deployment, scaling, and incident and log management. 

And this is coming from a fan of microservices architecture.

Hope you enjoyed the post. Interested to hear your thoughts on microservice architecture.

Image credit to https://microservices.io