Tag Archives: creative work

Lessons from Mark Manson’s “Models: Attract Women Through Honesty”

I picked up Mark Manson’s “Models: Attract Women Through Honesty” because I was intrigued by the title and because I am at a time in my life where I’d like to meet more interesting women. It did not disappoint. The book was insightful, and, like other compelling reads, it pushes me to look hard at myself and how I’ve been living my life, this time particularly on the subject of women. The concepts of neediness and vulnerability are, for me, the main takeaways.

Here are just a few of the noteworthy lines from the book:

  • In our post-industrial, post-feminist world, we lack a clear model of what an attractive man is. Centuries ago, a man’s role and duty was power and protection. Decades ago, it was to provide. But now? We’re not quite sure. We are either the first or second generation of men to grow up without a clear definition of our social roles, and without a model of what it is to be strong and attractive men.
  • Seduction is an interplay of emotions. Your movement or lack of movement reflects and alters emotions, not the words. Words are the side-effect. Sex is the side-effect. The game is emotions, emotions through movement.
  • In surveys among literally tens of thousands of women, across all cultures, ethnicities, age groups, and socio-economic standing, and even time periods, there’s one universal quality in men that they all find desirable: social status and access to resources. The amount in which they desire it varies from culture to culture and from age group to age group, but the desire for it is universal.
  • Social status is determined by how you behave around other people, how other people behave around you, and how you treat yourself.
  • Female arousal is somewhat narcissistic in nature. Women are turned on by being wanted, by being desired. The more physical assertiveness you pursue a woman with, the more aroused she becomes — sometimes even if she wasn’t interested in you to begin with.
  • How attractive a man is is inversely proportional to how emotionally needy he is. The more emotionally needy he is in his life, the less attractive he is and vice-versa. Neediness is defined by being more highly invested in other people’s perceptions of you than your perception of yourself.
  • All people eventually return to their baseline levels of investment. And until one is able to permanently alter his baseline level of identity investment in themselves, they will continue to attract the same types of women, and end up in the same failed relationships. Permanent change to one’s investment and neediness in their relationships with women is hard and a process that encompasses all facets of one’s life. But it’s a worthwhile journey. As a man, it may be the most worthwhile journey. And the key to it is probably something you wouldn’t expect. In fact, it’s something that most men turn their nose up to when they hear it. It’s vulnerability.
  • Making yourself vulnerable doesn’t just mean being willing to share your fears or insecurities. It can mean putting yourself in a position where you can be rejected, saying a joke that may not be funny, asserting an opinion that may offend others, joining a table of people you don’t know, telling a woman that you like her and want to date her. All of these things require you to stick your neck out on the line emotionally in some way. You’re making yourself vulnerable when you do them. In this way, vulnerability represents a form of power, a deep and subtle form of power. A man who’s able to make himself vulnerable is saying to the world, “I don’t care what you think of me; this is who I am, and I refuse to be anyone else.” He’s saying he’s not needy and that he’s high status.
  • Show your rough edges. Stop trying to be perfect. Expose yourself and share yourself without inhibition. Take the rejections and lumps and move on because you’re a bigger and stronger man. And when you find a woman who loves who you are (and you will), revel in her affection.
  • The biggest criticism of showing interest to a woman that you want to be with is that it immediately shows you as highly invested in her responses. When you say, “You’re cute and I wanted to meet you,” that translates roughly to, “Hi, I want to be with you and am officially invested in the prospect of it happening.” What they miss though is the sub-communication going on underneath what’s actually being said. The sub-communication is, “I’m totally OK with the idea of you rejecting me, otherwise I would not be approaching you in this manner.”
  • True honesty is only possible when it is unconditional. The truth is only the truth when it is given as a gift — when nothing is expected in return. When I tell a girl that she is beautiful, I say it not expecting anything in return. Whether she rejects me or falls in love with me isn’t important in that moment. What’s important is that I’m expressing my feelings to her. I will give compliments only when I am honestly inspired to give them, and usually after already meeting a woman and displaying to her that I’m willing to disagree with her, willing to be rejected by her and willing to walk away from her if it ever comes to that.

Takeaways from Derek Sivers’s “Anything You Want”

Derek Sivers, in his book titled “Anything You Want“, shares tales and lessons he’s learned when he started, built, and sold CD Baby, a global music distribution platform, for $22M (which will return to musicians after he dies). He’s an entrepreneur, but a divergent kind of entrepreneur from the ones I’m accustomed to, and I’ve grown fond of his philosophies in both business and in life. Perhaps it’s because of Seth Godin‘s influence, perhaps it’s because he’s a very slow thinker, perhaps it’s because the things he says just sounds about right.

Some favorite lines from the book:

  • Most people don’t know why they’re doing what they’re doing. They imitate others, go with the flow, and follow paths without making their own. They spend decades in pursuit of something that someone convinced them they should want, without realizing that it won’t make them happy. Don’t be on your deathbed someday, having squandered your one chance at life, full of regret because you pursued little distractions instead of big dreams. You need to know your personal philosophy of what makes you happy and what’s worth doing.
  • The key point is that I wasn’t trying to make a big business. I was just daydreaming about how one little thing would look in a perfect world. When you make a business, you get to make a little universe where you control all the laws. This is your utopia. When you make it a dream come true for yourself, it’ll be a dream come true for someone else, too.
  • Success comes from persistently improving and inventing, not from persistently doing what’s not working. We all have lots of ideas, creations, and projects. When you present one to the world and it’s not a hit, don’t keep pushing it as is. Instead, get back to improving and inventing. Present each new idea or improvement to the world. If multiple people are saying, “Wow! Yes! I need this! I’d be happy to pay you to do this!” then you should probably do it. But if the response is anything less, don’t pursue it.
  • If you’re not saying “Hell yeah!” about something, say no. When deciding whether to do something, if you feel anything less than “Wow! That would be amazing! Absolutely! Hell yeah!” then say no. When you say no to most things, you leave room in your life to throw yourself completely into that rare thing that makes you say, “Hell yeah!” We’re all busy. We’ve all taken on too much. Saying yes to less is the way out.
  • Never forget that absolutely everything you do is for your customers. Make every decision – even decisions about whether to expand the business, raise money, or promote someone – according to what’s best for your customers. If you’re ever unsure what to prioritize, just ask your customers the open-ended question, “How can I best help you now?” Then focus on  satisfying those requests. None of your customers will ask you to turn your attention to expanding. They want you to keep your attention focused on them. It’s counter-intuitive, but the way to grow your business is to focus entirely on your existing customers. Just thrill them, and they’ll tell everyone.
  • Watch out when anyone (including you) says he wants to do something big, but can’t until he raises money. It usually means the person is more in love with the idea of being big-big-big than with actually doing something useful. For an idea to get big-big-big, it has to be useful. And being useful doesn’t need funding. If you want to be useful, you can always start now, with only 1 percent of what you have in your grand vision. It’ll be a humble prototype version of your grand vision, but you’ll be in the game. You’ll be ahead of the rest, because you actually started, while others are waiting for the finish line to magically appear at the starting line.
  • Never forget why you’re really doing what you’re doing. Are you helping people? Are they happy? Are you happy? Are you profitable? Isn’t that enough?
  • We all grade ourselves by different measures:
    • For some people, it’s as simple as how much money they make. When their net worth is going up, they know they’re doing well.
    • For others, it’s how much money they give.
    • For some, it’s how many people’s lives they can influence for the better.
    • For others, it’s how deeply they can influence just a few people’s lives.
    • For me, it’s how many useful things I create, whether songs, companies, articles, websites, or anything else. If I create something that is not useful to others, it doesn’t count. But I’m also not interested in doing something useful unless it needs my creative input.
  • When you want to learn how to do something yourself, most people won’t understand. They’ll assume the only reason we do anything is to get it done, and doing it yourself is not the most efficient way. But that’s forgetting about the joy of learning and doing. Yes, it may take longer. Yes, it may be inefficient. Yes, it may even cost you millions of dollars in lost opportunities because your business is growing slower because you’re insisting on doing something yourself. But the whole point of doing anything is because it makes you happy! That’s it! You might get bigger faster and make millions if you outsource everything to the experts. But what’s the point of getting bigger and making millions? To be happy, right? In the end, it’s about what you want to be, not what you want to have. To have something (a finished recording, a business, or millions of dollars) is the means, not the end. To be something (a good singer, a skilled entrepreneur, or just plain happy) is the real point. When you sign up to run a marathon, you don’t want a taxi to take you to the finish line.

Lessons from Kent Beck and Martin Fowler’s “Planning Extreme Programming”

The first edition of “Planning Extreme Programming” by Kent Beck and Martin Fowler was published about 18 years (that long) ago, and already it says so much about how planning for software projects can be done well. It talks about programmers and customers, their fears and frustrations, their rights and responsibilities, and putting all those knowledge into a planning style that can work for development teams. It doesn’t have to be labeled XP, but it does need to help people be focused, confident, and hopeful.

Here are some noteworthy lines from the book:

  • Planning is not about predicting the future. When you make a plan for developing a piece of software, development is not going to go like that. Not ever. Your customers wouldn’t even be happy if it did, because by the time the software gets there, the customers don’t want what was planned; they want something different.
  • We plan to ensure that we are always doing the most important thing left to do, to coordinate effectively with other people, and to respond quickly to unexpected events.
  • If you know you have a tight deadline, but you make a plan and the plans says you can make the deadline, then you’ll start on your first task with a sense of urgency but still working as well as possible. After all, you have enough time. This is exactly the behavior that is most likely to cause the plan to come true. Panic leads to fatigue, defects, and communication breakdowns.
  • Any software planning technique must try to create visibility, so everyone involved in the project can really see how far along a project is. This means that you need clear milestones, ones that cannot be fudged, and clearly represent progress. Milestones must also be things that everyone involved in the project, including the customer, can understand and learn to trust.
  • We need a planning style that
    • Preserves the programmer’s confidence that the plan is possible
    • Preserves the customer’s confidence that they are getting as much as they can
    • Costs as little to execute as possible (because we’ll be planning often, but nobody pays for plans; they pay for results)
  • If we are going to develop well, we must create a culture that makes it possible for programmers and customers to acknowledge their fears and accept their rights and responsibilities. Without such guarantees, we cannot be courageous. We huddle in fear behind fortress walls, building them ever stronger, adding ever more weight to the development processes we have adopted. We continually add cannonades and battlements, documents and reviews, procedures and sign-offs, moats with crocodiles, torture chambers, and huge pots of boiling oil. But when our fears are acknowledged and our rights are accepted, then we can be courageous. We can set goals that are hard to reach and collaborate to make those goals. We can tear down the structures that we built out of fear and that impeded us. We will have the courage to do only what is necessary and no more, to spend our time on what’s important rather than on protecting ourselves.
  • We use driving as a metaphor for developing software. Driving is not about pointing in one direction and holding to it; driving is about making lots of little course corrections. You don’t drive software development by getting your project pointed in the right direction (The Plan). You drive software development by seeing that you are drifting a little this way and steering a little that way. This way, that way, as long as you develop the software.
  • When you don’t have enough time you are out of luck. You can’t make more time. Not having enough time is a position of helplessness. And hopelessness breeds frustration, mistakes, burnout, and failure. Having too much to do, however, is a situation we all know. When you have too much to do you can prioritize and not do some things, reduce the size of some of the things you do, ask someone else to do some things. Having too much to do breeds hope. We may not like being there, but at least we know what to do.
  • Focusing on one or two iterations means that the programmers clearly need to know that stories are in the iteration they are currently working on. It’s also useful to know what’s in the next iteration. Beyond that the iteration allocation is not so useful. The real decider for how far in advance you should plan is the cost of keeping the plan up-to-date versus the benefit you get when you know that plans are inherently unstable. You have to honestly asses the value compared to the volatility of the plans.
  • Writing the stories is not the point. Communicating is the point. We’ve seen too many requirements documents that are written down but don’t involve communication.
  • We want to get a release to the customer as soon as possible. We want this release to be as valuable to the customer as possible. That way the customer will like us and keep feeding us cookies. So we give her the things she wants most. That way we can release quickly and the customer feels the benefit. Should everything go to pot at the end of the schedule, it’s okay, because the stories at risk are less important than the stories we have already completed. Even if we can’t release quickly, the customer will be happier if we do the most valuable things first. It shows we are listening, and really trying to solve her problems. It also may prompt the customer to go for an earlier release once she sees that value of what appears.
  • One of the worst things about software bugs is that they come with a strong element of blame (from the customer) and guilt (from the programmer). If only we’d tested more, if only you were competent programmers, there wouldn’t be these bugs. We’ve seen people screaming on news groups and managers banging on tables saying that no bugs are acceptable. All this emotion really screws up the process of dealing with bugs and hurts the key human relationships that are essential if software development is to work well.
  • We assume that the programmers are trying to do the most professional job they can. As part of this they will go to great lengths to eliminate bugs. But nobody can eliminate all of them. The customer has to trust that the programmers are working hard to reduce bugs, and can monitor the testing process to see that they are doing as much as they should.
  • For most software, however, we don’t actually want zero bugs. (Now there’s a statement that we guarantee will be used against us out of context.) Any defect, once it’s in there, takes time and effort to remove. That time and effort will take away from effort spent putting in features. So you have to decide which to do. Even when you know about a bug, someone has to decide whether you want to eliminate the bug or add another feature. Who decides? In our view it must be the customer. The customer has to make a business decision based on the cost of having the bug versus the value of having another feature – or the value of deploying now instead of waiting to reduce the bug count. (We would argue that this does not hold true for bugs that could be life-threatening. In that case we think the programmers have a duty to public safety that is far greater than their duty to the customer.) There are plenty of cases where the business decision is to have the feature instead.
  • All the planning techniques in the world, can’t save you if you forget that software is built by human beings. In the end keep the human beings focused, happy, and motivated and they will deliver.

Takeaways from Kim Scott’s “Radical Candor”

There’s a lot I don’t know about being a kick-ass boss, or being a great manager. I’m pretty much still a work-in-progress in that area. Thankfully, Kim Scott’s “Radical Candor” points me to the questions I need to ask myself about it, and suggests steps I should consider taking in order to do better.

Some memorable lines from the book:

  • Relationships don’t scale. But the relationships you have with the handful of people who report directly to you will have an enormous impact on the results your team achieves.
  • You strengthen your relationships by learning the best ways to get, give, and encourage guidance; by putting the right people in the right roles on your team; and by achieving results collectively that you couldn’t dream of individually. When you fail to give people the guidance they need to succeed in their work, or put people into roles they don’t want or aren’t well-suited for, or push people to achieve results that are unrealistic, you erode trust.
  • It turns out that when people trust you and believe you care about them, they are much more likely to 1) accept and act on your praise and criticism; 2) tell you what they really think about what you are doing well and, more importantly, not doing so well; 3) engage in this same behavior with one another, meaning less pushing the rock up the hill again and again; 4) embrace their role on the team; and 5) focus on getting results.
  • We are all human beings, with human feelings, and, even at work, we need to be seen as such. When that doesn’t happen, when we feel we must repress who we really are to earn a living, we become alienated. That makes us hate going to work. To most bosses, being professional means: show up at work on time, do your job, don’t show feelings unless engaged in motivation or some such end-driven effort. The results is that nobody feels comfortable being who they really are at work.
  • It’s about finding time for real conversations; about getting to know each other at a human level; about learning what’s important to people, about sharing with one another what makes us want to get out of bed in the morning and go to work – and what has the opposite effect.
  • Challenging others and encouraging them to challenge you helps build trusting relationships because it shows 1) you care enough to point out both the things that aren’t going well and those that are and that 2) you are willing to admit when you’re wrong and that you are committed to fixing mistakes that you or otherwise have made. But challenging people directly takes real energy – not only from the people you’re challenging but from you as well – so do it only for things that really matter.
  • If nobody is ever mad at you, you probably aren’t challenging your team enough. The key, as in any relationship, is how you handle the anger. When what you say hurts, acknowledge the other person’s pain. Don’t pretend it doesn’t hurt or say it shouldn’t hurt – just show that you care. Eliminate the phrase “don’t take it personally” from your vocabulary – it’s insulting. Instead, offer to help fix the problem. But don’t pretend it isn’t a problem just to try to make somebody feel better.
  • If we have the data about what works, let’s look at the data, but if all we have are opinions, let’s use yours.
  • What growth trajectory does each person on my team want to be on right now? or Have I given everybody opportunities that re in line with what they really want? or What growth trajectory do my direct reports believe they are on? Do I agree? And if I don’t, why don’t I? Sometimes people really want to grow and are capable of contributing more than they have allowed to; at other times, they simply want more money or recognition but don’t really want to change the way they work or contribute any more than they do already. As the boss, you’re the one who’s going to have to know your direct reports well enough to make these distinctions and then have some radically candid conversations when you see things differently.
  • There’s nothing wrong with working hard to earn a pay check that supports the life you want to lead. That has plenty of meaning. Only about 5% of people have a real vocation in life, and they confuse the hell out of the rest of us. Your job is not to provide purpose but instead to get to know each of your direct reports well enough to understand how each one derives meaning from their work.
  • You don’t want to be the absentee manager any more than you want to be a micro-manager. Instead, you want to be a partner – that is, you must take the time to help the people doing the best work overcome obstacles and make their good work even better. This is time-consuming because it requires that you know enough about the details of the person’s work to understand the nuances. It often requires you to help do the work, rather than just advising. It requires that you ask a lot of questions and challenge people – that you roll up your own sleeves.
  • It won’t get better all by itself. So stop and ask yourself, how exactly, will it get better? What are you going to do differently? What will the person in question do differently? How might circumstances change? Even if things have gotten a little better, have they improved enough? If you don’t have a pretty precise answer to those questions, it probably won’t get better.
  • If you never ask a single question about a person’s life, it’s hard to move up on the “care personally” axis. probably the most important thing you can do to build trust is to spend a little time alone with each of your direct reports on a  regular basis. Holding regular 1:1s in which your direct report sets the agenda and you ask questions is a good way to begin building trust.
  • The platinum rule says, figure out what makes the other person comfortable, and do that.

One Month with Flutter: Some Notes

Wait, what, it’s already been a month? 😮

It apparently took me an exciting month to build a moderately intricate multi-page mobile app, powered by Flutter, with custom calendar and credit card views. The designs for the pages already existed, which was good because I did not want to worry about designing an app for my first try with Google’s SDK and the Dart language. I only wanted to test-drive writing the code for the user interface and find out what tools and structure I could use for managing state and data, given a relatively short span of time. A month isn’t enough to understand everything about the framework but I did learn a lot from the experience. A realization: I can totally write mobile apps now if I want to.

Some notes I’d like to remember from the exercise:

Five People and Their Thoughts (Part 7)

Today, here’s a new batch of compelling videos I’d like to share, for the curious:

  • What is Shift Left Testing? (by Alan Richardson, about shifting left and its meaning, consultancy speak, testing at all points of the software development process, and finding ways to improve our testing without resorting to consultancy speak)
  • How We Work #4: Known and Unknowns (by Basecamp, on creative work, known and unknown tasks and why it’s more important to track them rather than estimates, and using the hill chart)
  • A Better Technical Interview: 2018 (by Josh Greenwood, representing Test Double, about the binary hiring process existing in most industries, setting job and interview expectations, thinking about making the life of candidates better including the ones we don’t end up hiring, saying ‘Not Yet’ and providing constructive feedback, and the Bridge Agent)
  • How Open Source has Made Me and the Stuff I Make Better (by Kent Dodds, on open source software, remote work, improving technical and interpersonal skills, documentation, and asking better questions and learning from other people)
  • Office Politics for the Thin-Skinned Developer (by Justin Searls, about politics in the workplace, crazy organizational growth, building awareness, targeted empathy, being in the same page, how to make a difference, and allowing others to fail)

Notes from David Bryant Copeland’s “Build Awesome Command-Line Applications in Ruby 2”

The experience of writing and running automated checks, as well as building some personal apps that run on the terminal, in recent years, has given me a keen sense of appreciation on how effective command-line applications can be as tools. I’ve grown fond of quick programming experiments (scraping data, playing with Excel files, among others), which are relatively easy to write, powerful, dependable, and maintainable. Tons of libraries online help interface well with the myriad of programs in our desktop or out in the web.

Choosing to read “Build Awesome Command-Line Applications in Ruby 2” is choosing to go on an adventure about writing better CLI apps, finding out how options are designed and built, understanding how they are configured and distributed, and learning how to actually test them.

Some notes from the book:

  • Graphical user interfaces (GUIs) are great for a lot of things; they are typically much kinder to newcomers than the stark glow of a cold, blinking cursor. This comes at a price: you can get only so proficient at a GUI before you have to learn its esoteric keyboard shortcuts. Even then, you will hit the limits of productivity and efficiency. GUIs are notoriously hard to script and automate, and when you can, your script tends not to be very portable.
  • An awesome command-line app has the following characteristics:
    • Easy to use. The command-line can be an unforgiving place to be, so the easier an app is to use, the better.
    • Helpful. Being easy to use isn’t enough; the user will need clear direction on how to use an app and how to fix things they might’ve done wrong.
    • Plays well with others. The more an app can interoperate with other apps and systems, the more useful it will be, and the fewer special customizations that will be needed.
    • Has sensible defaults but is configurable. Users appreciate apps that have a clear goal and opinion on how to do something. Apps that try to be all things to all people are confusing and difficult to master. Awesome apps, however, allow advanced users to tinker under the hood and use the app in ways not imagined by the author. Striking this balance is important.
    • Installs painlessly. Apps that can be installed with one command, on any environment, are more likely to be used.
    • Fails gracefully. Users will misuse apps, trying to make them do things they weren’t designed to do, in environments where they were never designed to run. Awesome apps take this in stride and give useful error messages without being destructive. This is because they’re developed with a comprehensive test suite.
    • Gets new features and bug fixes easily. Awesome command-line apps aren’t awesome just to use; they are awesome to hack on. An awesome app’s internal structure is geared around quickly fixing bugs and easily adding new features.
    • Delights users. Not all command-line apps have to output monochrome text. Color, formatting, and interactive input all have their place and can greatly contribute to the user experience of an awesome command-line app.
  • Three guiding principles for designing command-line applications:
    • Make common tasks easy to accomplish
    • Make uncommon tasks possible (but not easy)
    • Make default behavior nondestructive
  • Options come in two-forms: short and long. Short-form options allow frequent users who use the app on the command line to quickly specify things without a lot of typing. Long-form options allow maintainers of systems that use our app to easily understand what the options do without having to go to the documentation. The existence of a short-form option signals to the user that that option is common and encouraged. The absence of a short-form option signals the opposite— that using it is unusual and possibly dangerous. You might think that unusual or dangerous options should simply be omitted, but we want our application to be as flexible as is reasonable. We want to guide our users to do things safely and correctly, but we also want to respect that they know what they’re doing if they want to do something unusual or dangerous.
  • Thinking about which behavior of an app is destructive is a great way to differentiate the common things from the uncommon things and thus drive some of your design decisions. Any feature that does something destructive shouldn’t be a feature we make easy to use, but we should make it possible.
  • The future of development won’t just be manipulating buttons and toolbars and dragging and dropping icons to create code; the efficiency and productivity inherent to a command-line interface will always have a place in a good developer’s tool chest.

Favorite Talks from Agile Testing Days 2017

There are two things that’s wonderful from last year’s Agile Testing Days conference talks: content focusing on other valuable stuff for testers and teams (not automation), and having as many women speakers as there are men. I hope they continue on with that trend.

Here’s a list of my favourite talks from said conference (enjoy!):

  • How To Tell People They Failed and Make Them Feel Great (by Liz Keogh, about Cynefin, our innate dislike of uncertainty and love of making things predictable, putting safety nets and allowing for failure, learning reviews, letting people change themselves, building robust probes, and making it a habit to come from a place of care)
  • Pivotal Moments (by Janet Gregory, on living in a dairy farm, volunteering, traveling, toastmasters, Lisa Crispin, Mary Poppindieck and going on adventures, sharing failures and taking help, and reflecting on pivotal moments)
  • Owning Our Narrative (by Angie Jones, on the history of the music industry so far, the changes in environment, tools, and business models musicians have had to go through so survive, and embracing changes and finding ways to fulfil our roles as software testers)
  • Learning Through Osmosis (by Maaret Pyhäjärvi, on mob programming and osmosis,  creating safe spaces to facilitate learning, and the power of changing some of our beliefs and behaviour)
  • There and Back Again: A Hobbit’s/Developer’s/Tester’s Journey (by Pete Walen, on how software was built in the old days, how testing and programming broke up into silos, and a challenge for both parties to go back at excelling at each other’s skills and teaming up
  • 10 Behaviours of Effective Agile Teams (by Rob Lambert, about shipping software and customer service, becoming a more effective employee, behaviours, and communicating well)

One Room, Working Together

For the past few weeks a number of programmers and myself have been tasked to build an initial prototype for a system rewrite project, handed to us by management. The merit of such project is a matter of discussion for another day; for now it is enough to say that the team has been given a difficult challenge, but at the same time excited about the lessons we knew we will gain from such an adventure.

There’s been several takeaways already in terms of technology know-how – dockerized applications, front-end development with Vue, repositories as application vendor dependency, microservices – just several of the things we’ve never done before.

But the great takeaway so far is the joy of literally working together, inside a room away from distractions, the team working on one task at a time, focused, taking turns writing application or test code on a single machine, continuously discussing options and experimenting until a problem is solved or until it is time to take a break. We instantly become aligned at what we want to achieve, we immediately help teammates move forward, we learn from each other’s skills and mistakes, we have fun. It’s a wonder why we’ve never done much of this before. Perhaps it’s because of working in cubicles. Perhaps it’s because there’s nearly not enough available rooms for such software development practice. Perhaps it’s because we’ve never heard anything about mob programming until recently.

I’m sure it won’t be everyday since we have remote work schedules, but I imagine the team spending more days working together like this from here on.

Doing Things Right, And Doing The Right Things

In testing software, automation is a tool that helps us re-run whatever repeatable checks we have on an application under test. We automate because we never have enough time to re-test everything by hand, and exploring the unknown parts of the apps we test is a far better use of our testing skills than following scripts. To automate is doing one thing right, within context, if it provides us the feedback we need. And that feedback we think we need from automation depends on what suites of tests are best repeated again and again, as well as what sort of tests costs more than the value they give.

There’s also tons of tools that helps us build good quality software. Even though we build more complex applications now than before, we have frameworks, libraries, intelligent IDEs, and other tools to help us spin up apps on a whim now too, ready to be modified as we see fit. Choosing the proper tools for the job is doing another thing right. But before we write any code, we need to be sure about the actual problem we are solving for our customer.

Yes, we need to do things right, from the get go if possible. They help us progress from one point to another faster than otherwise. However, I think it’s more important that we continuously take the necessary time to review whether we are doing the right things too, more important to actually get feedback and solve problems than merely adding tests and features.