DEV Community: Fagner Brack

The US$4000 JavaScript Interview Question Nobody Could Answer

Fagner Brack — Thu, 15 Jun 2023 22:07:27 +0000

Imagine being presented with a challenge that could seriously make you earn 0.1 Bitcoin (roughly US$4000 at current rates) for simply answering a JavaScript interview question. A wave of enthusiasm rushes through you until you read the question:

“From ES5 to ES6, was there any one website that would break due to the language update? If yes, which code?”

It wasn't a joke, and I actually had the money ready to transfer.

Fagner Brack on Twitter: "I've been giving hints in multiple places I posted this so people are starting to get closer to the actual answer so the 0.1BTC offer is over as that was only for those who could come up with the answer without hints, now it's easier knowing the wrong answers. / Twitter"

I've been giving hints in multiple places I posted this so people are starting to get closer to the actual answer so the 0.1BTC offer is over as that was only for those who could come up with the answer without hints, now it's easier knowing the wrong answers.

But here’s the catch: the question was never about a binary yes or no response. As an interview question, it was designed to be seen through the lens of tech interviews for business application development, their underlying purpose and their value to the organization.

And so, to much surprise, the correct answer is:

It doesn’t matter

The second question is moot.

Here’s why:

Interviews are supposed to hire new devs who can add more value to the organization. Better yet if they know more than the person interviewing them, that's what allows the organization to grow instead of becoming more of the same. Tech interviews, therefore, should focus on identifying developers who can proficiently code and design software, irrespective of the language, with perspectives that can add more value so the team grows. Instead, most interviews out there favour those who invest their time in learning programming niche specifics that play against real-world scenarios.

Imagine being a carpenter; you should be proficient in the techniques of building a house, not fixated on the brand of the hammer.

Using obscure JavaScript features in a way they could break when transitioning from older to newer language versions is an indication that the domain is too coupled to the language and there's a skill gap in software engineering expertise. The whole premise of the question, in the context of an interview, is misguided.

Unless you’re hiring for a cook, don't set up your questions to embrace those who can make more spaghetti.

What We Learn from The Answers

A series of insightful "great wrong answers" came up during this challenge, and they serve a valuable point. Typically, programming language designers would make breaking changes affecting code rarely used, usually when your domain models are coupled to the programming language.

In the context of an interview, the knowledge that breaking changes exist is fundamental, the specifics are not as it's easy for anyone to spend 5 minutes googling them or looking at the language spec. However, the correct answer is to design systems at the correct level of abstraction, ensuring that such a problem wouldn’t arise. The correct answer is to ensure that a programming language update wouldn’t affect your code by writing simple, long-lasting code designed around Domain Models.

"Probably this company is not for me"

— One the answers that came the closest

For example, take the code below. It's coupled to the programing language Literals and would fail while trying to group based on a prop called 'toString', so it requires crazy hops to fix like the use of Object.prototype.call internally or TypeScript interfaces to limit the prop lookup:

const groupBy = <T extends AnyDomainInterfaceInThisCaseCartItem>(
  cartItems: T[],
  prop: keyof T
): Record<string, T[]> => {
  ...
};
const cart = groupBy(cartItems, prop);
storage.save(cart);

Instead, a decoupled design would be more domain-specific like this (in an object-based paradigm):

const cart = ShoppingCart(config);
cart.addItem(cartItem);
storage.save(cart);

Or this (in an immutable functional-based paradigm), using the principles of state = fn(command, state):

cart = execute(addToCart, cart);
storage.save(cart);

NOTE: The examples above are NOT extensive, there are many ways to decouple Domain Models from the language, but those are just two out of many possible ways of doing this for the domain of e-commerce; there are tradeoffs on each approach. Regardless, the Domain Models will evolve over time and the final result tends to be much more specific than my examples, depending on which "kind" of e-commerce subdomain you're operating on. That's why many frameworks don't work together with Domain Models, they lock your code to the framework's domain, not your application's domain.

In the examples above, can you see how the "groupBy" function has absolutely NO domain information other than variable names? The encapsulated function is too generic, designed for general reusability (excessive DRY), and relies upon primitives (Primitive Obsession) as the function is coupled to an ArrayLiteral of ObjectLiteral, (Array[] for short). None of that has any meaning whatsoever in the context of e-commerce, only for those who contribute to an Open Source library like Lodash. In the context of application development, the model is too generic; it has no value.

Ironically, those who provide complex interview answers or delve into very cryptic, underground knowledge about the language are often those who perform poorly in overall software engineering; yet, they're easier to get hired because the market is optimized for {TrendyStuff} roles. They focus excessively on language, frameworks, or technology, failing to comprehend that these elements constantly evolve and code that is coupled to them is a liability.

As an interviewer, when you interview based on such grounds, you end up hiring people who think the same way, fostering groupthink, hindering innovation, and preventing the dissemination of knowledge of software design. Ultimately leading to a higher-than-necessary cost of development.

Hiring based on technology skills foster groupthink, hinder innovation, and prevent dissemination of software design knowledge.

This is the reason why most companies struggle to hire someone better than their existing workforce: they will test candidates against what they believe to be valuable, even if one can just google or write a test to check how the code works; not against an actual domain scenario.

It eventually leads to layoffs, which is a reaction of organizations to the constant production of low-value software and infinite rewrite cycles. The irony is palpable when software engineers who have experience with Domain Modeling and software design fail an interview crafted by programmers who don't understand any of that. That happens even when those interviewers bear the title of Senior or Principal/Staff Engineers, which happens more often than not.

What can we learn from all this?

So, as we look back at this exciting challenge, it’s clear that the real lesson lies not in knowing the intricacies of JavaScript’s evolution. It is in understanding what truly matters when it comes to hiring staff for the purpose to build competent, successful, adaptable and innovative software engineering teams. Those are things most people don't know how to do, as proven by the many attempts to answer this question in the context of the JavaScript language.

Just like some devs lost the opportunity to win US$4000 here, organizations are missing the opportunity to turn millions due to their outdated tech interviewing practices.

So here's one variation for a great answer to the original question:

It doesn't matter.

If the code breaks after an ES update it will probably break after a framework or library update and it will be hard to fix; depending on how coupled things are, we may have to rewrite the whole application. That also means the code is too smart and doesn't provide real-life value to the organization.

I would design the code in such a way the domain is not coupled to the programming language, frameworks, libraries, etc. Therefore, updates or specific language/framework/libraries idiosyncrasies are NOT likely to break my code. In the rare cases where it does, the domain is encapsulated so third party code is easy to fix.

Also, you might be able to easily hire programmers from other programming language communities who can perform with minimal quality impact, as long as they understand the fundamentals, patterns and paradigms of software engineering and domain modeling.

THAT is the answer.

Domain Modeling skills for application development (such as Domain-Driven Design), obliterate the need for engineers to learn 90% of the features of any programming language or framework. In that context, interviews about the language make absolutely no sense. If the intention is to assess whether the engineer will perform in the organization technically, the question is wrong. They should assess basic patterns of the core paradigms, not cryptic underground language syntax puzzles.

That's why tools like HackerRank are the worst thing to ever happen in modern times to the software engineering industry.

The right answer, in the context of qualifying a developer against application development experience, is to change the question…

… because after all, The Problem You Solve Is More Important Than The Code You Write.

Unfortunately, we all know other fellow programmers interviewing that person will lack the skills to understand the whole premise of the answer, which is to create software that has BUSINESS VALUE. The interviewer will fail the interviewee probably for being scared of the unexpected answer, even if they have the ability to adapt to a less-than-ideal scenario.

If an organization knows how to engineer good software, the only outcome for the interviewee should be: Congratulations, you passed!

Unfortunately, those organizations (including teams within big ones) are very rare. I have been fortunate enough to work with a few of them in my career.

And you, what was your experience in tech interviews?

If you know an organization that would be friendly to valuable software development without forcing good engineers into a management role, I'm open to work. Get in touch with me via LinkedIn!

In the meantime, happy tech interviewing!

Thanks to Igor J. Santos for their insightful input on this post.

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.

I Made 7 Predictions For The Web For The Next 5 Years

Fagner Brack — Thu, 01 Jun 2023 22:01:42 +0000

Now 7 Years Later, Here’s What Happened.

Google Trends "oracle" search term, it seems like I'm becoming less relevant Worldwide.

There’s nothing more stupid than trying to make predictions. Humans are very bad at it, and speaking to myself in the third person at least allows me to make fun of my own stupidity without feeling bad.

There's this illusion Venture Capitalists and Angel Investors have it all figured out; it turns out the rate of success of their predictions is as precise as heads or tails. Who knew? I thought they were actually paid to know what they were doing.

Regardless, 7 years ago I decided to make 7 Predictions For The Web In The Next 5 Years. This post was in draft for some time so I guess I’m a little late to the party. Should probably have been 5 predictions for the next 7 years instead =/.

The idea was to reflect on where things were heading so that I could revisit them again after the time elapsed.

The time to reflect on that is now.

1. I predicted: Progressive Web Apps will overrun mobile apps R.O.I., but mobile apps won’t become obsolete (yet)

Mobile apps are not even close to becoming obsolete, nor "yet". We have Instagram, TikTok, UberEATS and a myriad of other apps primarily tailored and optimised for mobile phones outside the Web. It's not like you can't provide equivalent experiences on the web, it's just that the skills necessary to do so and the speed in which JavaScript-based Web Technologies move make it hard for the mobile web to be a viable business.

Google Trends shows that the interest in Progressive Web Apps topped in 2018/2019/2020. However, it started to decrease quite significantly towards 2021 and came back in 2023.

Web Apps, though, never stop growing:

By the way, what the hell with all those September spikes?

Websites don't seem to care very much:

Seems like the Web is having a naming crisis. What’s next, Web Crypto?

Only a 2021 fad it seems…

2. I predicted: The web will be totally based on components

That one was a precise hit, though I should have added a few caveats.

Nowadays everything is a component, as much as everything was a "class" 10 years ago. React, and JSX are the most popular toolings, though they come at the cost of JavaScript Everywhere™ (better be careful) and front-ends with minimum requirements of 2GB payload size in the first run.

The "Modern Web" setup is completely feasible today, including React, Webpack and their 10¹³² dependencies. After all, every customer should be able to load your website with an iPhone 35 and the processing power of trillions of Apollo Rockets in their pockets, including an internet connection as speedy as the latest dial-up.

Every company seems to be copying Facebook’s tech stack in an apparent attempt to copy its success. I'm not sure if that will work, but the question remains if React is the future because of components, or if components are the future because of React.

Only time will tell.

3. I predicted: Functional Programming will be the fundamental basis for writing JavaScript

Speaking of React, they changed from using the render() as a method within classes to use functions that accept props and return JSX. That was a long time ago. It was a significant improvement in simplicity towards the functional paradigm. As I wrote 6 years ago , A Front-End Component Is A Function that Returns the View, glad they made the move.

In regards to Functional Programming reaching the mainstream, it seems like it hasn't outside the JS community. Luckily I didn't say it would:

I mean, Java and C# are still big things and Micro$oft is trying to eliminate the "Java" from JavaScript and replace it with "Type" on the likes of C#. Looks like there's some grudge there:

Watch out for the next news: "TC39 has been renamed to TS40".

4. I predicted: The Brave browser will become the second most used browser in the world and will drive the ad-block philosophy the same way Opera drove the Tabs philosophy

Unless BrendanEich has changed the UserAgent of Brave to be exactly the one of Safari (there's some precedent there), the prediction has failed.

Some places say Brave market share is 0.05%. However “Brave Browser Makes Tracking Market Share Difficult”: https://kinsta.com/browser-market-share/

One thing I got it right: Chrome is dominating as the first.

Safari on the other hand is the second.

3. Functional Programming will be the fundamental basis for writing JavaScript

React changed from classes to functions that accept props and return JSX. Functional Programming is everywhere, I haven't seen blog posts talking about Prototypal Inheritance in JS for a few years now.

I guess I got this one right.

5. I predicted: State-based architecture with Event Sourcing (AKA Redux) will be the standard pattern on how to design the front end.

For the web, the standard hasn’t changed. It continues being a spaghetti stored in S3 while architecture and design are thrown into the bin. Only the names of the tools are different, the mess is the same. If someone got it right, it was Kevlin Henney with “Old is the new New”: https://www.youtube.com/watch?v=AbgsfeGvg3E. Timeless!

In hindsight, I was too optimistic something would have changed.

The best way to measure Event Sourcing in the front end is by looking at the popularity of the Redux library, which is a half-baked functional event-sourcing implementation for the browser where "describing what happened" in an Object Literal is called an "action" instead of an "event".

Redux is on quite a constant star increase but seems to be reaching a plateau:

React grows more, easy to predict where the trend is going:

Vue is quite following React, both trying to reach the skies like the opening of an anime episode:

On another note, people are getting tired of Bootstrap:

Redux is Following the same trend as jQuery:

On a comparison, Bitcoin did jump in 2017 so ppl seem to be more interested in Crypto and Distributed Systems.

Yet the popularity of the Bitcoin repo is still at the same level as that of jquery, probably the popularity of all crypto projects is spread around the other 9 million "coins" out there.

6. I predicted: the core of JavaScript libraries and projects will start to be built without being tied to a specific state-based architecture implementation or framework.

I did that with js-cookie a long time ago but it seems like the trend hasn't followed to other components, maybe a few here and there. Angular was the new jQuery, NPM also became the new jQuery, and now React is the new NPM but it kind of uses NPM for distribution so it's weird. Everything is a "React" component. Building front-end components in JavaScript with frameworks and libraries "pluggable to it" doesn't seem to have picked up the pace and it probably never will. After all, creating JavaScript components doesn't help you being hired as The Next Senior {TrendyStuff} Engineer.

7. A standard pattern will emerge to write CSS concerns in JavaScript

Ok, I know what you're thinking. I'm not even sure if the styled-components trend actually made its way to the mainstream. React definitely did but very few people seem to be using styled-components nowadays, happy to be proven wrong:

So let's wrap it up:

I evaluated seven predictions about the web I made five years ago. The predictions included the rise of Progressive Web Apps, component-based web design, functional programming in JavaScript, the success of the Brave browser, the dominance of state-based architecture with Event Sourcing, and the incorporation of CSS in JavaScript.

Reflecting on these, it appears that while mobile apps are not becoming obsolete, Progressive Web Apps did peak in interest, went down, and then back again. The web did indeed become largely component-based, with React and JSX gaining popularity. Functional programming is now fundamental to JavaScript and React. However, the Brave browser did not achieve the success that can be measured (maybe it's intentional as it's a privacy browser). The web’s architecture with React remains complex despite small Redux adoption, while CSS concerns in JavaScript didn’t become mainstream as expected.

The predictions yielded a mixed bag of hits and misses. Which is expected when you try to be the Oracle. Speaking of which, I should also go and sue someone.

I'll be right back…

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.

Unlocking AI’s Potential for Programming Productivity and Flow Without the Pitfalls

Fagner Brack — Sun, 28 May 2023 22:01:40 +0000

Some developers might be sceptical about using AI tools like Github Copilot due to the occasional incorrect answers. However, my experience has been quite the opposite. Although I was very sceptical at the beginning, the real power of these tools lies in their ability to increase productivity and maintain the creative flow, not to provide correct answers. In this blog post, we’ll explore the ways in which AI tools can help you harness these benefits and transform your development process.

Although AI tools like Copilot may sometimes provide incorrect answers, their real value lies in their ability to improve productivity and facilitate action and flow. By providing an initial approach to coding problems and keeping developers engaged, AI tools can help you stay focused and maintain your creative momentum.

It’s been shown[1] that after only 20 minutes of interrupted performance, people reported significantly higher stress, frustration, workload, effort, and pressure. It can take 15 minutes or more for people to get back into the flow after being interrupted during a programming task [2]. However, what I noticed in my own experiments is that AI tools like Github Copilot help me regain my focus in a matter of seconds. By offering personalized suggestions within the IDE, the copilot can quickly bring me back to my task and minimize the time spent regaining my bearings.

Here's an example: I was designing a simple validation function using TDD (Detroit School), and I got distracted by something outside and lost my focus. I asked ChatGPT to "continue TDD to build the next test from where I left off". After a few enter key presses, it suggested the wrong test based on the previous ones, but at least by analysing its suggestion, I managed to delete it and get back on track, knowing exactly what the next step was.

Here's the thing: AI tools can provide a starting point for tackling familiar problems, even if their initial solutions are not perfect. This technique is reminiscent of psychological methods used to overcome procrastination and maintain action and flow [3]. By offering an imperfect solution, AI prompts developers to recall the correct approach, allowing them to efficiently tackle problems they’ve solved numerous times before.

Overcoming the Dreaded “Blank Page”

The “blank page” refers to the overwhelming feeling of staring at an empty screen, unsure of how to start a project or tackle a problem. AI tools like Copilot can help developers overcome this barrier by providing initial suggestions and code snippets to kick-start the creative process.

The convenience of staying within the IDE view and receiving personalized suggestions makes AI tools like Copilot invaluable for keeping developers on track and avoiding time-consuming rabbit holes. By providing targeted assistance within the familiar environment of the IDE, developers can maintain their focus and avoid distractions, which is very useful for those with ADHD.

The benefits of using AI tools like copilot in software development extend far beyond their potential for generating code. Their real power lies in their ability to help developers regain their flow, maintain focus, and overcome common barriers such as the dreaded “blank page.” It allows for an accessible work environment for those with ADHD.

So, maybe that tap on the shoulder won’t be so costly now that you have a tool that can help you get back into the flow?

Thanks to Jeremy Nagel for their insightful input on this post.

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.

References

1: Mark, G., Gudith, D., & Klocke, U. (2008). The cost of interrupted work: More speed and stress. ACM.

2: Parnin, C., & Rugaber, S. (2010). Resumption strategies for interrupted programming tasks. Springer Science+Business Media, LLC.

3: Pychyl, T. A., & Flett, G. L. (2012). Procrastination and self-regulatory failure: An introduction to the special issue. Journal of Rational-Emotive & Cognitive-Behavior Therapy, 30(4), 203–212. https://doi.org/10.1007/s10942-012-0149-5

The FATE Metrics for Hiring

Fagner Brack — Thu, 25 May 2023 22:02:11 +0000

I've been speaking lately to a lot of engineers, and I tend to complain about the current state of interviewing without coming up with a solution for the technical interviews. For that reason, I am excited to introduce a concept I've been working on for 15+ years, observing and researching hiring and interviews. It's not a full solution, but another tool or your toolbelt.

Introducing the FATE Metrics

An aggregate of metrics for engineers and hiring managers to assess their technical interview process.

Photo by Mikail McVerry on Unsplash

The FATE Metrics , which stands for Feedback, Accuracy, Time, and Effort, is a set of metrics designed to benchmark a technical interview process by focusing on the candidate's experience, particularly in software engineering, but applicable across all roles and industries. By improving the hiring process, companies can ensure they’re attracting and retaining the best talent, ultimately shaping the FATE of their organization and the candidate’s career. In this blog post, I will provide an overview of the FATE Metrics and explain how they can benefit both candidates and organizations.

Each metric has a score of 0–10. Where 0 is " Very low" , 10 is " Very high" , and 5 is " Medium".

Feedback (F)

Feedback measures the usefulness of the feedback for rejections, both the company to the candidate and vice-versa. However, we'll focus on the candidate's experience.

An ideal feedback score would include a detailed, personalized response from the hiring manager, helping the candidate understand why they did or did not secure the position. To provide effective feedback, it should be objective, constructive, guided, paced, and encouraging, as discussed in various research papers on effective feedback (see references).

Useful Feedback translates to a high score.

Very low score: The software engineering candidate receives a generic rejection email from a no-reply address with no information on their performance during the interview process.

Medium score: The software engineering candidate receives feedback from the company that they decided not to continue with the process using an email that can be replied to. The candidate replies to the email asking for specific feedback on how they can improve; the company responds that they decided to go with another candidate. The candidate requests more specific feedback, but the company does not reply back.

Very high score: A software engineering candidate receives a personalized email from the hiring manager detailing the strengths and areas for improvement observed during the interview process, with specific examples and guidance for future growth. It doesn't matter if the response is automated as long as it's crafted to the candidate's circumstances. The company asks for feedback from the candidate on how they can improve their own process.

Accuracy (A)

Accuracy evaluates how closely the interview process aligns with the job requirements of the role the candidate is applying for.

A high-accuracy interview process involves simulations or real-life problem-solving exercises that closely mirror the candidate’s future responsibilities rather than generic or unrelated code challenges. A low-accuracy interview is based on irrelevant l33t code and abstract technical questions that can be easily looked up online. High accuracy is based on real-life.

High Accuracy translates to a high score.

Very low score: A software engineering candidate is asked to solve abstract algorithmic problems during the interview, which are unrelated to the daily tasks they would perform in the role. In this kind of interview, interviewers send crazy questions and expect that the candidate would ask the right questions to remove ambiguity to get to the solution of the problem. It gives an unreasonable advantage to low-skill engineers that have trained for this kind of interview or read the book Cracking the Code Interview. Examples are "Given a bus, how many baseballs would you fit in them?" or "Given points x, y and z in a multi-dimensional dataset, what is the shortest distance between x and z?".

Medium score: A software engineer is shortlisted based on their CV by a human and is invited to participate in a coding session with another engineer and asked to solve a domain problem that is representative of the actual work they will be doing. However, the work does not match their skills or the expectations for the role.

Very high score: A software engineering candidate is filtered through self-assessment of competencies and Big 5 assessment, and that information is compared to the team's requirements using the findings of the relevant scientific research on the topic. Once shortlisted, they participate in a pair programming or solo programming session with a member of the team they're applying for. The candidate is given a real-life domain scenario that is representative of the actual work they will be doing in the role, but without the interviewer knowing the solution for the problem.

Examples are "We work in an internal developer tools team, and we've been asked by other devs to design an API to get information about the weather; where would you start?" or "We work in a customer-facing website for payments, we've been asked to implement a gateway to interact with multiple payment providers, where would you start?"

Time (T)

Time refers to the duration of the interview process until both parties reach to an outcome.

An efficient process is short, with minimal rounds and a limited number of people involved. Lengthy, convoluted processes can cause confusion and negatively impact the candidate’s experience.

A quick process translates to a high score.

Very low score: A software engineering candidate goes through multiple rounds of interviews, spanning several weeks or even months, with no clear communication regarding the next steps or timeline to the conclusion. Asking for feedback by email yields no reply.

Medium score: A software engineering candidate goes through several rounds of interviews over the course of a few weeks, with some communication about the next steps and timeline. However, there may be occasional delays or lack of clarity, and the candidate might need to follow up with the company for updates.

Very high score: A software engineering candidate completes a streamlined interview process. After their application, there's one shortlist stage and then one or two more stages to receive a decision within less than a week.

Quicker interviews tend to yield low accuracy if done incorrectly. However, good interviews are quicker and with high accuracy.

Effort (E)

Effort assesses the amount of work required from the candidate during the interview process. A low-effort process might involve answering pre-set questions and making a decision simply by talking to your peers. On another hand, a high-effort process could require take-home assignments or extensive open-ended questions and exercises like HackerRank.

A low-effort process translates to a high score.

Very low score: A software engineering candidate is asked to complete a lengthy HackerRank and take-home assignment with no compensation for their time and effort. Later, they need to travel in person to the company HQ to have a set of 6 interview rounds with 12 different people. The in-person interview spans multiple days.

Medium score: A software engineering candidate goes through a moderately demanding interview process that includes a combination of online assessments and a few rounds of interviews with different team members. The process may require a reasonable amount of effort but is not overly demanding or time-consuming.

Very high score: A software engineering candidate is shortlisted after a skill self-assessment and may get a response straight away with the possibility to talk to the hiring manager if there's a mistake. After being shortlisted, the remote interview process balances the candidate’s effort with the value of the insights gained, such as a well-structured technical interview. The interview with another engineer tests some of the aspects the candidate self-assessed to cross-verify some of the responses but not all, followed by a behavioural interview.

The FATE Metrics provide an objective measurement tool for sensing the quality of the interview process in software engineering and beyond, with the ultimate goal of achieving a 10/10 score in each category.

However, these should be used like the instruments of a plane where it helps you sense the environment, not evaluate it completely, as achieving 10/10 doesn't mean your interview becomes magically perfect. By embracing the FATE Metrics, companies can identify areas where their hiring process may be falling short and make targeted improvements that will benefit not only their organization but also the candidates and, potentially, the industry as a whole.

As the landscape of software engineering and other industries continues to evolve rapidly, attracting and retaining top talent becomes increasingly crucial. By employing the FATE Metrics in the hiring process, companies can ensure they’re providing the best possible experience for candidates, creating a positive impression and setting the stage for a successful working relationship. In turn, this will help to shape the FATE of the organization, the candidate’s career, and even the industry as a whole, promoting growth and innovation in the long run.

If you want me to come over and help you with your interview process, contact me on Twitter, LinkedIn or Github.

Bonus: I plan to publish an archive containing years of interview processes analysed using the FATE metrics. Also, a list of questions in which organizations can self-assess their interview process.

Stay tuned by subscribing! 📻

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.

References

Poston, K. L. (2013). Feedback That Sticks: The Art of Effectively Communicating Neuropsychological Assessment Results. Oxford University Press.
Costa, Paul T., Jr., and Robert R. McCrae. “Personality in Adulthood: A Six-Year Longitudinal Study of Self-Reports and Spouse Ratings on the NEOPI.” Journal of Personality and Social Psychology, vol. 48, no. 2, 1984, pp. 159–165. JSTOR, www.jstor.org/stable/2095160.
Dreyfus, Hubert L., and Stuart E. Dreyfus. “A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition.” Operations Research Center, University of California, Berkeley, 1980.

You Won’t Believe What Comes Next: The Solution for Clickbait Headlines

Fagner Brack — Sun, 21 May 2023 22:01:47 +0000

It’s time to prioritize substance over style and let AI take the reins in generating headlines that truly reflect the value of content.

We’ve all fallen victim to the irresistible allure of clickbait headlines. Whether it’s “You won’t believe what happens next!” or “10 secrets you need to know,” these tantalizing titles are designed to capture our attention and encourage us to click. While they may be effective at driving traffic, they often lead us down a rabbit hole of low-quality content and endless scrolling.

I've seen it firsthand on HackerNews and Reddit.

Photo by Andrey Metelev on Unsplash

I call it the “Law of Clickbait Headlines”, which is a variation of "Goodhart's Law" for the endless work of protecting communities from submitting links with clickbait headlines. The proposition is simple: as people block or ignore clickbait, another one tends to take its place over time. Consequently, it becomes an endless cycle, making it increasingly difficult for quality content to break through the noise as people continue to game the system.

According to “dredmorbius” on HackerNews:

Algolia, at this writing, the words “how did we get here” appear in HN submissions (net of flags and edits) 363 times. That’s exceeded by the even more tiresome “this changes everything” (571 results). Both should be hellbanned IMO. I’m having an email exchange with dang over this presently.

— “How did we get here” search on hn.algolia.com

— “This changes everything” search on hn.algolia.com

The Problem with User-Generated Headlines

Headline-based websites like Hacker News and Reddit are notorious for their abundance of clickbait titles. These platforms favour advertisers and content creators who can craft attention-grabbing headlines, while quality content without the marketing flair often goes unnoticed.

The Veritasium YouTube channel, for example, is a great channel that talks about real science and shares valuable and credible scientific research but is compelled to use clickbait-style headlines and images for its videos to attract viewers. Unfortunately, this means that many people from the general audience do not have access to well-delivered evidence-based research simply because the researchers either lack the skills or knowledge to create good headlines.

But what if there was a way to break this cycle and prioritize valuable content over catchy headlines?

Enter Artificial Intelligence.

Instead of relying on user-generated headlines, AI could be employed to create titles that accurately represent the content’s relevance, leaving edits to trusted community members (high karma), which are fed back into the AI for tuning. By making AI responsible for crafting headlines, we can focus on the substance of the content rather than its click bait ability (is that an actual word? 🤔).

AI-generated headlines have the potential to level the playing field, allowing quality content to shine regardless of the creator’s marketing prowess. Moreover, this approach could help discourage advertisers from exploiting clickbait strategies and instead motivate them to produce more valuable content.

The internet is a treasure trove of incredible content, but it’s often hidden behind a wall of clickbait headlines. By leveraging AI to generate headlines that prioritize the content’s relevance over click bait ability, we can break the cycle of clickbait and ensure that valuable research and information are no longer overshadowed by flashy titles. It’s time to take a stand against clickbait culture and embrace the power of AI to promote quality content that truly deserves our attention.

Don't be afraid of the crazy machines; the future is bright and full of colours.

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.

Finding the Sweet Spot: Pros and Cons of Mob Programming, Pair Programming, and Solo Work in…

Fagner Brack — Thu, 18 May 2023 22:01:42 +0000

Finding the Sweet Spot: Pros and Cons of Mob Programming, Pair Programming, and Solo Work in Software Development

In the dynamic world of software development, striking a balance between collaboration and autonomy is essential for optimizing productivity, knowledge sharing, and team cohesion. Various working styles, such as Mob Programming, Pair Programming, and Solo Work, exist to address these needs. Drawing from my 15+ years of experience managing teams and implementing these working styles in various settings, this blog post will delve into the pros and cons of each working style and provide insights on how to find the sweet spot between collaboration and autonomy within your team.

Photo by Chang Duong on Unsplash

My Experience with Mob Programming, Pair Programming, and Solo Work

Throughout my career, I’ve had the great opportunity to work with teams that employed Mob Programming, Pair Programming, and Solo Work, witnessing the effectiveness of each approach firsthand:

At MYOB, my team implemented Mob Programming, leading to a tenfold increase in performance and becoming the best-performing team in the company during my tenure.
While working at Service NSW, I utilized principles of Mob Programming to teach Test-Driven Development (TDD) principles within five weeks for a team of 6 engineers.
At Lexicon (while working at IAG), I acted as a Subject matter Expert on Mob Programming to help the teams with a successful migration project by orchestrating three Mob Programming groups simultaneously, achieving the desired results in an astonishing 3 months within the tight timeframes that many deemed impossible.

The Importance of Experience and Psychological Safety in Mob Programming

It’s crucial to have someone experienced in Mob Programming working with the team, as this ensures the approach is effectively implemented and increases the likelihood of success. Psychological Safety is a must, and the entire team needs to understand the value of trying Mob Programming for the task at hand, with a clear goal of solving the specific issues they are facing.

A top-down imposition of a working style rarely works and often reduces psychological safety. Google’s Project Aristotle, which studied the factors that contribute to team success, found that psychological safety was the most important element in high-performing teams.

Ensuring that team members feel comfortable taking risks, sharing ideas, and voicing concerns is vital for the success of Mob Programming or any collaborative working style.

Pair Programming (2 people working simultaneously on one task on one screen)

Pros:

Sharing Experience and knowledge and speeding up domain learning
More ideas to solve complex issues / can speed up task solution
Ensures focus on debugging / Exploratory work / less procrastination
Early Feedback in the design and code to decrease the cost of change exponentially (instead of increasing the cost of change exponentially)
Minimizes the Truck Factor (team resiliency) / Work continuity if one team member gets sick, goes on leave, or has jury duty

Cons:

Less freedom to explore a problem space without communication overhead quickly
Pressure from peers for work completion might compromise on quality
Breaks, coffee, and other needs can disrupt the session

Mob Programming (3+ people working simultaneously on one task on one screen)

Pros:

Enhanced Sharing Experience, Knowledge Sharing, and Learning
More ideas to solve complex issues than pairing/speed up task solutions significantly
Ensures focus on debugging / Exploratory work / no procrastination
Early Feedback in the design and code to decrease the cost of change
Makes some rituals and meetings unnecessary; everyone is already together
Nullifies the Truck Factor (team resiliency)
Strong flow / Work continuity and easy context re-acquisition after breaks or absences
Ensures team buy-in and early conflict resolution
Breaks and personal needs can be managed individually without coordination

Cons:

Not suitable for simple tasks
The longer time spent on single tasks when multiple tasks could have been completed
Staying in Mob Programming quiet for too long may hide individual performance problems and reduce accountability for an individual

Solo Work (1 person working on one task on one screen)

Pros:

Easy to get into the flow
Context Switch costs less / is Easier to switch
Short-term conflict avoidance
Working on one’s own time without coordination
Zero reliance on the Internet for remote work

Cons:

Truck Factor maximized / Knowledge retained on individuals instead of shared as a team
More PR Review comments / Issues are solved async and too late / Increase WIP
Thoroughness/Team Alignment on the design is weaker than working together with all minds
Easier to get blocked staring at the "blank screen" / Hindered in problem-solving
Procrastination is more likely

Finding the Right Balance

To find the sweet spot between collaboration and autonomy, consider the following factors:

Task complexity: Opt for Mob or Pair Programming for complex tasks; that is, when the problem doesn't have a clear cause/effect, and Solo Work for simpler tasks; that is when the solution has a clear cause/effect.
Team dynamics: Assess team members’ strengths, weaknesses, and communication styles to determine the most suitable working style.
Personal preferences: Take individual preferences into account and provide incentives for team members to work in their preferred mode when appropriate.
Time constraints: In time-sensitive situations where quality is not a goal, Solo Work or Pair Programming may be more suitable than Mob Programming.
Project goals: Consider the overall objectives of the project and the need for collaboration, knowledge sharing, and team alignment to guide the choice of working style.
Physical limits: Consider if the physical structure allows for a comfortable session for Pair Programming and Mob Programming. Most workspaces are optimised for siloed work.

Final Thoughts

There is no one-size-fits-all approach to software development, and finding the sweet spot between collaboration and autonomy depends on various factors unique to each team and project. By understanding the tradeoffs associated with Mob Programming, Pair Programming, and Solo Work, teams can make informed decisions about their working styles and ultimately improve productivity, knowledge sharing, and team cohesion.

My experience across different organizations, big and small, has reinforced the importance of tailoring these working styles to each team’s unique needs and circumstances to achieve the best possible outcomes.

Dogmas should be off the table.

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.

Book Summary: The Self-Taught Programmer

Fagner Brack — Wed, 17 May 2023 22:01:57 +0000

by Cory Althoff

“The Self-Taught Programmer” is a comprehensive guide to learning to code and becoming a successful software developer, even without a formal computer science degree. This book is particularly relevant to those who are embarking on a self-guided journey into programming.

As a self-taught programmer, I can personally attest to the value of the strategies and concepts outlined in “The Self-Taught Programmer”. Early in my career, I found myself applying many of these ideas instinctively, even without a comprehensive guide to direct me. It’s truly gratifying to see a book like this that distils some of the core ideas of self-directed learning into a form that can be easily consumed and applied by future professionals in the field. While the book is a great starting point, remember that the journey of learning and growing in the field of programming is a continuous one.

Keep exploring, keep coding, and keep learning!

The most valuable points from the book are:

Understanding the Basics

Althoff stresses the importance of thoroughly understanding the basics of programming, including variables, control structures, data structures, and syntax.

For example, he provides exercises that help beginners grasp the concept of loops, a fundamental control structure in programming. However, in real-world coding, understanding the basics also involves knowing when and how to use these structures most effectively in different programming scenarios.

Learning a Programming Language

The book guides readers through the process of learning Python, a versatile and beginner-friendly programming language. Althoff provides numerous practical examples and exercises to reinforce learning.

For example, he introduces Python’s list data structure and demonstrates its use in various contexts. However, becoming proficient in a programming language also involves understanding its idiomatic usage and best practices, something that often comes with experience and is not covered extensively in the book.

Problem-Solving Skills

The book emphasizes the importance of problem-solving skills and logical thinking in programming. It provides various problems and their solutions to help readers hone these skills.

For example, Althoff presents a problem on finding the largest number in a list and walks through the solution. In real-world programming, problem-solving often involves understanding the requirements, breaking down the problem, and devising a solution step by step.

Understanding Algorithms and Data Structures

Althoff introduces the concept of algorithms and data structures, providing several examples. He explains the basics of search algorithms, sorting algorithms, and common data structures.

For instance, he demonstrates how to use a binary search algorithm in Python. However, in real-world software development, understanding algorithms and data structures also requires knowing when to use a specific algorithm or data structure to optimize performance or solve a particular problem.

Building Projects

The book encourages readers to apply what they’ve learned by building projects. Althoff argues that building real-world projects is one of the best ways to learn and reinforce programming concepts, and it’s also crucial for building a portfolio to showcase to potential employers.

For example, Althoff guides readers through building a web scraper using Python. However, in real-world projects, programmers also need to consider factors like code maintainability, scalability, and the use of version control systems, which are not extensively covered in the book.

Career Advice

The book provides guidance on how to land a job as a programmer, including tips on networking, preparing for interviews, and writing a compelling resume.

For instance, Althoff provides tips on preparing for common programming interview questions. However, breaking into the tech industry also involves continuous learning and adapting to new technologies, which is not a major focus of the book.

“The Self-Taught Programmer” is a valuable resource for those looking to learn programming on their own. However, it’s important to supplement the knowledge gained from the book with additional resources and practical experience to fully prepare for a career in software development.

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.

Book Summary: Programming Pearls

Fagner Brack — Tue, 16 May 2023 10:24:30 +0000

by Jon Bentley

“Programming Pearls” is a classic text in the field of computer science, offering a series of practical problems and their solutions to foster problem-solving skills. The book holds substantial relevance for software engineers as it encourages critical and creative thinking to tackle complex programming challenges.

However, it’s important to note that this text is more academically inclined, focusing heavily on algorithms and data structures. In real-life programming scenarios, especially given the processing power of modern computers, we don’t always need to rely on the most optimized algorithms. Often, understanding and solving the business problem at hand can lead to solutions that may not involve complex algorithms, an aspect not deeply explored in the book.

The most valuable points from the book are:

Problem-Solving and Program Design

The book emphasizes the importance of thoughtful problem-solving and careful program design, arguing that it’s not enough to write code that works but that good code should also be efficient, readable, and maintainable.

For example, in one chapter, Bentley discusses the problem of sorting a large file of numbers and shows how a simple algorithm can be more efficient than a complex one when taking into account the constraints of the problem. Also, he demonstrates a case where a clever application of binary search can significantly speed up a seemingly simple text formatting task.

Efficiency and Performance

Bentley discusses the importance of writing efficient code and understanding how different algorithms and data structures can affect the performance of a program. He provides a variety of examples and case studies to illustrate these points.

For example, in one problem, he discusses the trade-offs between using an array or a linked list to implement a word processing program. Also, Bentley shows how small changes in an algorithm can lead to significant improvements in performance, such as the use of a binary search instead of a linear search in a word lookup program.

Testing and Debugging

The book also focuses on the importance of rigorous testing and debugging, highlighting the need to consider edge cases and potential sources of error. Bentley provides a number of strategies for testing and debugging and emphasizes the value of a systematic approach to finding and fixing bugs.

For example, in a chapter about testing, he describes a systematic approach to testing a binary search algorithm, using a set of carefully chosen test cases to ensure that all possible edge cases are covered. Also, Bentley illustrates how a methodical approach to debugging can help locate the source of an error in a complex program.

Algorithm Design and Data Structures

“Programming Pearls” delves into various algorithm design techniques and data structures, providing practical applications and solutions. Bentley’s approach is to take a problem, analyze it, and solve it using the most appropriate data structures and algorithms.

For example, he illustrates how using a heap data structure can help solve the problem of finding the kth largest number in an array efficiently. Also, Bentley demonstrates how a well-designed algorithm can drastically reduce the time complexity of a problem, such as finding anagrams.

By focusing on practical problem-solving, thoughtful design, and careful implementation, “Programming Pearls” provides valuable insights for software engineers and anyone interested in improving their programming algorithm skills.

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.

Detection of AI-Generated Text and the P vs NP Problem

Fagner Brack — Sun, 14 May 2023 22:01:55 +0000

The detection of AI-generated text has become a hot topic nowadays. However, the relationship between this challenge and the P vs NP problem, one of the most enigmatic questions in computer science, sheds light on the true complexity of the task. Dive into this captivating exploration to learn why AI-generated text detection may be an unattainable goal unless you've found the solution for the P vs NP problem.

The P vs NP Problem: A Brief Overview

The P vs NP problem is a fundamental question in computer science that has puzzled mathematicians and programmers for decades. It revolves around the relationship between two classes of problems: those that are solvable in polynomial time (P) and those whose solutions can only be verified in polynomial time but are much harder to solve (NP).

P problems are considered “easy” to solve because they can be tackled efficiently by algorithms. Examples include sorting a list of numbers, finding the shortest path between two points in a graph, or determining if a number is prime.

NP problems, on the other hand, are those for which solutions can be verified quickly, but finding a solution may be time-consuming. Examples include the travelling salesperson problem, where the goal is to find the shortest route that visits a series of cities and returns to the starting point, or the subset sum problem, which involves finding a subset of numbers that sum to a given target value.

The P vs NP question asks two questions:

Is every problem in NP also in P (P = NP)?

In other words, does every problem whose solution can be quickly verified also has an efficient algorithm to find the solution? If P equals NP, it would mean that even the most complex problems have efficient algorithms to solve them, which would have profound implications for cryptography, optimization, and many other fields.

Are some problems in NP but not in P (P ≠ NP)?

In other words, do some problems whose solution cannot be quickly verified NOT have an efficient algorithm to find the solution? If P does not equal NP, then there are problems that are inherently more difficult to solve than to check.

Today, all of our cryptography infrastructure is built under the assumption that P ≠ NP, so anything that proves them wrong is worth global news for a long, long time. More than when we came up with the Theory of Relativity.

The Clay Mathematics Institute has designated the P vs NP problem as one of its seven Millennium Prize Problems, offering a $1 million prize to anyone who can provide a correct solution. Despite decades of research, no one has been able to prove whether P equals NP or not, and the question remains one of the most significant open problems in computer science, with a million-dollar prize for whoever solves it.

The Connection between P vs NP and AI Text Detection

One-way hashes are mathematical functions that take an input (or “message”) and return a fixed-size string of bytes, usually as a hash value. The output appears random and is uniquely associated with the input. Under the assumption of P ≠ NP, it’s impossible to reverse-engineer the input from the output and even small changes to the input result in vastly different hash values. One-way hashes are widely used in cryptography, password storage, and data integrity verification.

hash = fn(message)

Now, let’s connect one-way hashes, the P vs NP problem, and AI-generated text detection. AI-generated content is produced by complex algorithms, such as large language models (LLMs), which are designed to create human-like text. The process of generating text from these models is a black box and can be thought of as a one-way function, similar to a hash function. Under the P ≠ NP assumption, once the text is generated, it’s incredibly difficult to determine the exact model, its parameters, or the prompt used to create the text.

content = fn(prompt)

Detecting AI-generated text is an NP problem because, although it might be possible to verify whether a given text is AI-generated, finding an efficient algorithm to consistently and accurately identify AI-generated content remains elusive. If P were equal to NP, an efficient algorithm would exist, enabling us to accurately detect AI-generated text without false positives.

However, since the P vs NP question remains unsolved, we don’t know if such an algorithm exists, and you have to be very sceptical of anyone who claims they found one and didn't win the million-dollar prize yet. They might have found an algorithm without touching the P/NP problem, but that discovery will be as groundbreaking. It's one thing to break a hash function that you can inspect and test reproducibly; another completely different is to reverse-engineer an LLM which is changing all the time and may not yield the same response for the same input prompt. You can use the same seed, but updates to the model will change the behaviour regardless.

Current AI Generation Tools and Their Limitations

In practice, detecting AI-generated text is challenging because these algorithms produce increasingly human-like content, making it hard to differentiate from genuine human writing. Additionally, AI-generated text can be modified with simple edits, further evading detection. For example, give me any AI-generated content, and I can bypass any detector with less than 5 edits for every 1000 words.

For example: According to the AI content detector, “ZeroGPT,” 92.26% of the United States Constitution was allegedly written by AI.

As a result, without a breakthrough in solving the P vs NP problem (such as proving P = NP) or a breakthrough in an AI detection algorithm (which is almost impossible because AI is a dynamic everchanging black box), it’s unlikely that we’ll develop a foolproof method to detect AI-generated content without false positives. It will be a game of catchup where every model update will change its default template and trigger a change to every AI Detection algorithm.

The Unlikely Solution: P = NP

In the context of AI-generated text detection, proving that P equals NP could have significant implications. If P were equal to NP, it would mean that an efficient algorithm exists for all problems whose solutions can be verified quickly, including the detection of AI-generated text. This would allow for the development of a foolproof method to identify machine-generated content without false positives or false negatives, ultimately enhancing the accuracy and reliability of AI text detection.

However, proving P = NP does not automatically provides the answer. It's possible to prove P = NP or P ≠ NP without actually providing an example.

Also, the likelihood of proving P equals NP remains uncertain, as the question has persisted as one of the most challenging and enigmatic problems in computer science. If someone were to successfully demonstrate that P equals NP, they would not only revolutionize the field but also receive substantial rewards and recognition.

Additionally, solving the problem would likely lead to international acclaim, a lasting impact on various industries, and potential advancements in cryptography, optimization, and other fields that rely on complex problem-solving algorithms. That person (or team) would definitely win a Turing Award.

An impossible task?

The detection of AI-generated text remains an elusive goal, closely tied to the unsolved P vs NP problem. Until this enigma is unravelled, confidently identifying AI-generated content remains a distant dream. In the meantime, be very sceptical of those who promise to be "AI detectors", and how they managed to do so without solving a problem that nobody else was able to.

Do you know anyone who claims who have developed an AI-generated text? Hit me up, and I will put them to the challenge.

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.

Related Material

How quantum computers will be able to decrypt RSA in 10 years' time

Book Summary: Domain-Driven Design Distilled

Fagner Brack — Sat, 13 May 2023 22:01:38 +0000

by Vaughn Vernon

“Domain-Driven Design Distilled” (AKA DeDeDe-DeDe-DeDe…) is a sequel to the previous DDD book from Vaugh Vernon. It's a concise guide to understanding and implementing Domain-Driven Design (DDD) principles in software development. The book focuses on the core concepts of DDD, with practical examples to help developers apply these principles in real-world projects.

The most valuable points from the book are:

Ubiquitous Language

Ubiquitous Language is a shared vocabulary between domain experts and developers to facilitate clear communication and ensure a shared understanding of the domain. The book recommends this common language be used throughout the development process, from requirements gathering to implementation.

For example, when developing an e-commerce system, domain experts and developers should use the same terms, such as “Order,” “Product,” and “Customer,” to avoid confusion and miscommunication.

Bounded Context

Bounded Context is a concept that emphasizes the importance of defining clear boundaries around a particular domain or subdomain, ensuring that models and concepts within the context remain consistent and coherent.

For example, in a large organization with multiple departments, each department might have its own Bounded Context, ensuring that the models and concepts within each department are consistent and do not leak into other departments. This is "loose coupling and cohesion".

Entities, Value Objects, and Aggregates

DDD distinguishes between Entities, Value Objects, and Aggregates as the core building blocks of domain models. Entities have a unique identity and lifecycle, while Value Objects are immutable and represent a specific value. Aggregates are clusters of related domain objects that are treated as a single unit for consistency and transactional purposes.

For example, in a banking system, an Account can be an Entity, a MonetaryAmount can be a Value Object, and a BankTransaction can be an Aggregate that consists of multiple related objects, such as Debit and Credit.

Domain Events

Domain Events are occurrences within the domain that triggers a change in state or a business process. They are used to decouple components and promote a more modular, event-driven architecture. This is different than any other concept of "event", which may carry a different meaning, say a NodeJS event.

For example, in an e-commerce system, a ProductSold event can be triggered when a customer completes a purchase, allowing other components to react to this event, such as updating inventory or sending a confirmation email.

Repositories and Factories

Repositories and Factories are patterns used in DDD to manage the lifecycle of domain objects (usually Aggregates). Repositories are responsible for persisting and retrieving domain objects, while Factories handle the creation and initialization of domain objects.

For example, an OrderRepository can be responsible for saving and retrieving Order domain objects, while an OrderFactory can create new Order objects based on specific business rules.

Strategic Design and Context Mapping

Strategic Design and Context Mapping are techniques used in DDD to manage the complexity of large-scale systems and the relationships between different Bounded Contexts. Context Mapping helps identify dependencies, overlaps, and potential conflicts between different Bounded Contexts.

For example, when integrating multiple systems, Context Mapping can be used to identify areas of potential misalignment or integration challenges.

Book Summary: Implementing Domain-Driven Design

Fagner Brack — Fri, 12 May 2023 22:01:01 +0000

by Vaughn Vernon

“Implementing Domain-Driven Design” is a comprehensive guide to applying Domain-Driven Design (DDD) principles in real-world software projects. The book provides practical examples, best practices, and in-depth explanations of DDD concepts to help developers create maintainable and scalable software systems.

The most valuable points from the book are:

Building a Rich Domain Model

Creating a rich domain model that accurately represents the business domain is crucial in DDD. This involves identifying key domain concepts, such as Entities, Value Objects, and Aggregates, and modelling their relationships, behaviours, and constraints.

For example, in an e-commerce application, the domain model should represent concepts like Customer, Order, and Product, along with their respective behaviours and business rules.

Context Mapping and Integration Patterns

Context Mapping is essential for understanding the relationships between different Bounded Contexts in a large-scale system. The book discusses various integration patterns for communication between Bounded Contexts, such as Shared Kernel, Customer-Supplier, and Anti-Corruption Layer.

For example, an Anti-Corruption Layer can be used to isolate a legacy system from a new system, ensuring that the new system remains decoupled from the legacy system’s model and implementation details.

Domain Events and Event-Driven Architecture

Domain Events represent significant occurrences in the domain and can be used to decouple components and create an event-driven architecture. The book explains how to design, publish, and handle Domain Events to improve system modularity and scalability.

For example, an OrderShipped Domain Event can be published when an order is shipped, allowing other components to react to this event, such as updating the customer’s order history or sending a shipping confirmation email.

Applying DDD to Legacy Systems

The book provides guidance on applying DDD principles to legacy systems, including strategies for refactoring, modularization, and incremental improvements while preserving existing functionality.

For example, a monolithic legacy application can be gradually refactored into multiple Bounded Contexts, making it easier to manage, maintain, and evolve over time.

Team Collaboration and Organization

Implementing DDD effectively can't be done in silos. It requires close collaboration between domain experts, developers, and other stakeholders. The book discusses techniques for fostering collaboration, such as Event Storming, which is a collaborative modelling technique that helps teams explore and understand complex business domains.

For example, during an Event Storming session, domain experts and developers can work together to identify key domain events, commands, and aggregates, leading to a shared understanding of the domain and a more effective domain model.

Tactical Patterns and Techniques

The book covers various tactical patterns and techniques for implementing DDD, such as Repository and Factory patterns, Specification pattern for complex validation and querying, and designing Aggregate roots for consistency and transactional boundaries.

For example, a UserRepository can be used to manage the persistence of User Entities, while a UserFactory can handle the creation and initialization of User instances based on specific business rules.

By providing practical examples, best practices, and in-depth explanations of DDD concepts, “Implementing Domain-Driven Design” serves as a valuable resource for developers looking to create maintainable, scalable, and robust software systems that accurately model complex business domains.

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.

Book Summary: RESTful Web Clients - Enabling Reuse Through Hypermedia

Fagner Brack — Thu, 11 May 2023 22:01:38 +0000

by Mike Amundsen

“RESTful Web Clients: Enabling Reuse Through Hypermedia” provides insights into designing and building RESTful web clients that effectively consume and interact with web services. The book emphasizes the importance of leveraging hypermedia and existing web standards to create reusable and flexible clients.

It talks about REST as an Architectural Style for Distributed Systems based on Roy Fielding's Dissertation, not the way REST is used in the wild, which is RPC over HTTP using JSON.

DISCLAIMER: The code examples are not taken from the book.

The most valuable points from the book are:

Understanding RESTful Web Services

The book starts by providing a solid understanding of RESTful web services, focusing on the concepts of resources, representations, and hypermedia.

Hypermedia-Driven Web Clients

Mike emphasizes the importance of designing web clients that are driven by hypermedia, allowing them to adapt to changes in the web service without requiring updates.

For example, a web client uses hypermedia controls provided by the web service to navigate through resources and perform actions, ensuring that the client can adapt to changes in the API without breaking.

// Control response for media types with +json suffix
{
  actions: [{
    name: 'prev',
    target: 'http://server.com/resource-a',
    method: 'POST'
  }, {
    name: 'next',
    target: 'http://server.com/resource-b',
    method: 'PUT'
  }]
};

Leveraging Web Standards

The book highlights the importance of using existing web standards such as HTML, CSS, and JavaScript to build RESTful web clients, enabling reuse and reducing development effort.

For example, a developer builds a web client using HTML and JavaScript, allowing it to be used across various platforms and devices without the need for additional development.

<!-- Navigation interception using Code on Demand -->
<script>
  [...document.querySelectorAll('form')].forEach((action) => {
    action.addEventListener('submit', (event) => {
      event.preventDefault();
      // Custom handling of navigation
    });
  });

</script>

<!-- Control response for text/html media type -->
<form name="prev" method="POST" action="http://server.com/resource-a">
  <button type="submit"></button>
</form>
<form name="next" method="POST" action="http://server.com/resource-b">
  <button type="submit"></button>
</form>

Web Client Patterns and Anti-Patterns

The author discusses various patterns and anti-patterns for building RESTful web clients, helping developers avoid common pitfalls and build more robust and maintainable clients.

For example, a developer learns to avoid tightly coupling the web client to a specific API structure, ensuring that the client remains flexible and adaptable to changes in the web service.

const response = {
  actions: [{
    name: 'prev',
    target: 'http://server.com/resource-a',
    method: 'POST'
  }, {
    name: 'next',
    target: 'http://server.com/resource-b',
    method: 'PUT'
  }]
};

// This:
const query = queriable(response);
const action = {
  url: query('actions[name="prev"]->["target"]') || '' // self,
  method: query('actions[name="prev"]->["method"]') || 'GET'
};
const response = await fetch(action);

// Instead of this:
const action = {
  url: response.actions[0].target,
  method: response.actions[0].method
};
const response = await fetch(action);

Building Custom Web Clients

The book provides guidance on building custom web clients that can work with different media types and hypermedia controls, increasing the reusability and flexibility of the clients.

For example, a developer creates a custom web client that can handle various media types through Content Negotiation, such as XML and JSON, allowing it to work with different web services without requiring significant modification.

const HALResponse = await fetch({
  ...
  headers: {
    'Accept': 'application/hal+json'
  }
});

const HTMLResponse = await fetch({
  ...
  headers: {
    'Accept': 'text/html'
  }
});

By applying the concepts and best practices presented in “RESTful Web Clients: Enabling Reuse Through Hypermedia,” developers can build more flexible, maintainable, and reusable web clients that effectively interact with RESTful web services inside and outside an organization.

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.