Lessons from Lucius Seneca’s “On The Shortness Of Life”

One interesting topic I’ve come across this year in a few podcasts I listen to is Stoicism. William Irvine introduced the school of thought in an episode of the Art of Manliness podcast and Ryan Holiday wrote a practical guide about it for entrepreneurs on The Tim Ferriss Show. It has practical applications in daily life, and because of that I’d like to eventually learn more about what to practice and its how’s and why’s. For now though, I thought that reading up on Seneca’s essay ‘On the Shortness of Life‘ would be a good starting point.

Here are some notes from the essay:

  • It’s not that we have a short time to live, but that we waste much of it. Life is long enough, and it’s been given to us in generous measure for accomplishing the greatest things, if the whole of it is well invested. But when life is squandered through soft and careless living, and when it’s spent on no worthwhile pursuit, death finally presses and we realize that the life which we didn’t notice passing has passed away. So it is: the life we are given isn’t short but we make it so; we’re not ill provided but we are wasteful of life.
  • Look at those whose prosperity draws crowds: they are choked by their own goods. How many have found their wealth a burden! How many are drained of their blood by their eloquence and their daily preoccupation with showing off their abilities! How many are sickly pale from their incessant pleasures! How many are left with no freedom from the multitude of their besieging clients!
  • What foolish obliviousness to our mortality to put off wise plans to our fiftieth and sixtieth year, and to want to begin life from a point that few have reached!
  • The person who devotes every second of his time to his own needs and who organizes each day as if it were a complete life neither longs for nor is afraid of the next day. For what new kind of pleasure is there that any hour can now bring? Everything has been experienced, everything enjoyed to the full. For the rest, fortune may make arrangements as it wishes; his life has already reached safety. Addition can be made to this life, but nothing taken away from it – and addition made in the way that a man who is already satisfied and full takes a portion of food which he doesn’t crave and yet has room for.
  • I am always astonished when I see people requesting the time of others and receiving a most accommodating response from those they approach. Both sides focus on the object of the request, and neither on time itself; it is requested as if it were nothing, granted as if it were nothing. People trifle with the most precious commodity of all; and it escapes their notice because it’s an immaterial thing that doesn’t appear to the eyes, and for that reason it’s valued very cheaply – or rather, it has practically no value at all.
  • The greatest waste of life lies in postponement: it robs us of each day in turn, and snatches away the present by promising the future. The greatest impediment to living is expectancy, which relies in tomorrow and wastes today. You map out what is in fortune’s hand but let slip what’s in your own hand. What are you aiming at? What’s your goal? All that’s to come lies in uncertainty: live right now.
  • There is a common saying that it was not in our power to choose the parents we were allotted, and that they were given to us by chance; yet we can be born to whomever we wish. There are households of the most distinguished intellects: choose the one into which you’d like to be adopted, and you’ll inherit not just the name but also the actual property, which is not to be hoarded in a miserly or mean spirit: the more people you share it with, the greater it will become.
  • Honors, monuments, all that ostentatious ambition has ordered by decree or erected in stone, are soon destroyed: there’s nothing that the long lapse of time doesn’t demolish and transform. But it cannot harm the works consecrated by wisdom: no age will efface them, no age reduce them at all. The next age and each one after that will only enhance the respect in which they are held, since envy focuses on what is close at hand, but we more freely admire things from a distance.
  • It is nevertheless better – believe me – to know the balance sheet of one’s own life than that of the public grain supply.
  • In this mode of life much that is worth studying awaits you: the love and practice of the virtues, forgetfulness of the passions, knowledge of how to live and to die, and deep repose.
Advertisements

There Are Many Interesting Things I

There’s a lot of interesting things in the software development and testing space, lots of stuff to study and learn. The past few years I spent learning to build automated checks in Java and Ruby has been a fun ride and I’ve learned a great deal about the concepts, benefits, and pitfalls of automation. Now I’m at that point where I’m thinking of what other areas I’d like to study next. There’s JavaScript – which I’ve recently started educating myself how to use through freeCodeCamp’s ‘Beau teaches JavaScript’ playlist and James Shore’s ‘Let’s Code Test-Driven Javascript subscription course – because I can quickly write small tools with through the browser. After digesting the basics, I’ll likely spend more months understanding the TDD process and build something, hopefully becoming proficient in it before the year ends.

But there are some other intriguing experiments I’d like to try, some of which are:

Maybe you’d like to test them too. 🙂

Notes from Creating Great Teams (How Self-Selection Lets People Excel) by Sandy Mamoli and David Mole

Here’s an always challenging question: how are great software development teams formed? Managers, scrum masters, we all struggle to create continuous progress within our groups. And we know that there’s lots of factors in why that is – communication, skills, individual quirks. Sandy Mamoli and David Mole tells us that self-selection is the answer, and their book, Creating Great Teams (How Self-Selection Lets People Excel), provides us with the details.

Here are some notes from the book:

  • Fundamentally, two factors determine whether a group will forge itself into a team: 1) Do these people want to work on this problem? 2) Do these people want to work with each other? Neither a computer program nor a manager can answer these questions. Only the employees who will do the work can.
  • Self-selection is a facilitated process of letting people self-organize into small, cross-functional teams. Based on the belief that people are at their happiest and most productive if they can choose what they work on and who they work with, we think it’s the fastest and most efficient way to form stable teams.
  • The best motivators are autonomy, mastery, and purpose. Autonomy provides employees with freedom over some or all of the four main aspects of work: when they do it, how they do it, who they do it with, and what they do. Mastery encourages employees to become better at a subject or task that matters to them and allows for continuous learning. Purpose gives people an opportunity to fulfill their natural desire to contribute to a cause greater and more enduring than themselves.
  • No one chooses to work on more than one team or project. Time and again organizations fall into the trap of optimizing resources rather than focusing on outcomes. People often believe that multitasking, having people work across several projects, and focusing on resource utilization are the keys to success, when in reality they’re not.
  • People communicate face to face. There are barely any discussions about process or how to communicate. Team members just talk and coordinate and collaborate as needed. Things are much faster that way.
  • In the spirit of letting people control their way of working, we never mandate whether a squad should run scrum, kanban, their own special creation, or a traditional way of working. Following Daniel Pink’s principles of motivation, one of the key forms of autonomy is being in control of your processes. Giving people autonomy over who they work with should be extended by letting them choose how they work together.
  • There are two agile practices we believe should remain mandatory: retrospectives and physical story walls (if you are co-located).
  • It’s fair to say that sometimes employees don’t want to work with each other. And that’s okay. People know whether they’re going to gel in a squad with a particular person, and if not, it makes sense they would choose not to work with him or her. Self-selection, unlike management selection, allows them to make that choice.

Takeaways from Elisabeth Hendrickson’s “There’s Always A Duck”

Elisabeth Hendrickson’s book “There’s Always A Duck” has been around for a number of years but I have only been able to read it recently. Now I know what she meant about ducks. They’re literally about ducks, but also about people too. People are different, and yet we share similarities. We experience things, we communicate with each other, and we learn and get better because of those experiences. Her book tells us stories of her adventures and the lessons she’s discovered along the way, and it was nice to have had a glimpse of what she saw and felt with her encounters with software project teams and everyone involved.

Some takeaways:

  • The vast majority of programmers I have met are diligent, capable folk. They truly care about the quality of their work and want the software they produce to be useful. They work hard to make sure they are implementing the right features and writing solid code.
  • The next time you’re tempted to think of your programmers as idiots, incompetents, or quality hostile, remember that no matter what else they may be, they’re people first. Even if it seems like they’re hostile or incapable, it is far more likely that they are having a very human reaction to a particularly bad situation.
  • And before you blame someone else for a mistake, remember the last time you made one. I’ve made some real whopper mistakes in my time. We all have, whether or not we choose to admit them or even remember them. It may be that some programmers don’t care about users, but it’s more likely that bugs are honest mistakes made under difficult circumstances.
  • Even when we are speaking the same language and about the same thing, it’s hard enough to communicate.
  • The point wasn’t to catch every possible error. What seems to go wrong most often? What errors are difficult to see at first glance, and thus require concentration to prevent? What causes the most damage when it happens?
  • Janet doesn’t know anything about the ins and outs of creating software. She probably doesn’t want to know. She just wants to serve her customers well. And this software is not helping. Back at corporate, the Steering Committee, Requirements Analysts, Designers, Programmers and Testers are congratulating themselves on a solid release. What they don’t see is Janet’s pain. The feedback loop is broken. The team back at corporate has no mechanism to find out whether the software is any good. Oh, sure, they’ll detect catastrophic problems that cause servers to go down. But they won’t see the little things that cause long queues at the front desk of the hotel.
  • Testers naturally notice details. Not only do we notice, but we think about what we noticed, we attempt to interpret our observations to explain why things might be that way, we ask others if they noticed, we question our assumptions, and we poke and prod at things to see if our understanding is correct. We use our observations to inform us, and in doing so discover underlying causes and effects we otherwise might miss.
  • I sometimes fall into the trap of thinking that the first problem I see must be THE problem that needs to be solved. Perhaps the problem I spotted is indeed worth correcting, but I almost never manage to spot the true critical issue at first glance.
  • Both fear and excitement stem not from observable reality but rather from speculation. We are speculating that the bugs that we know about and have chosen not to fix are actually as unimportant to our users as they are to us. We are speculating that the fact we have not found any serious defects is because they don’t exist and not because we simply stopped looking. We are speculating that we knew what the users actually wanted in the first place. We are speculating that the tests we decided not to run wouldn’t have found anything interesting. We are speculating that the tests we did run told us something useful. None of it is real until it is in the hands of actual users. The experience those users report is reality. Everything else is speculation.
  • It’s not because Agile is about going faster. It’s because structuring our work so that we can ship a smaller set of capabilities sooner means that we can collapse that probability wave more often. We can avoid living in the land of speculation, fooling ourselves into thinking that the release is alive (or dead) based on belief rather than fact. In short, frequent delivery means we live in reality, not probability.
  • Hire the right people. If that means keeping a critical position on the team open longer than anticipated, so be it. It’s better to have an under- staffed team of highly motivated, talented, skilled people than a fully staffed but ineffective team. Remember that hiring mistakes often take only a few minutes to make, and months of wasted time to undo.
  • Listen. There are always signs when a project is in trouble: missed milestones, recurrent attitude problems, general confusion about the project. Sometimes these signs indicate a dysfunctional team, sometimes they’re just normal bumps along the road, and sometimes they are early warning signs of major problems. The only way to tell the difference is to listen carefully to what the team members have to say.
  • The best way to get people to accept change is to make it more fun, and more rewarding, to do things the new way.
  • Choose a path that takes you in the direction you want to go. Don’t choose a path simply because it takes you away from the swamp you want to avoid.

Favorite Talks from Selenium Conference Austin 2017

It’s amazing that the recently concluded Selenium Conference over at Austin Texas continues to live up to expectations, building up on the previous conferences and keeps delivering quality talks on automation and testing. And what’s more interesting is to know how they’ve been keeping up with everything with help from the Software Freedom Conservancy and the testing community. There’s even a European Selenium Conference happening on October 9-10, which I’m very much looking forward to.

Meanwhile, here are some of my favorite talks from the Austin conference:

  • Automate Windows and Mac Apps with the WebDriver Protocol (by Dan Cuellar, Yosef Durr, and Stuart Russell, about easily automating Windows and Mac apps using Appium)
  • Automating Restaurant POS with Selenium – A Case Study (by Jeffrey Payne, about automating a point-of-sale system for testing, including credit card readers, printers, cash drawers, and caller IDs)
  • Selenium State of the Union (by Simon Stewart, on an overview of the W3C spec process and about naming things in the Selenium project, how APIs should be correct and how people won’t write their own, how not everyone is a sophisticated developer, and how testing is under resourced)
  • Leverage your Load Tests with JMeter and Selenium Grid (by Christina Thalayasingam, on adding load tests for your system using JMeter and Selenium Grid in combination)
  • Selenium and the Software Freedom Conservancy (by Karen Sandler, on the safety and efficacy of proprietary medical devices and how often open-source software are more likely to be safer and better over time, and about what kind of organization the Software Freedom Conservancy is and how it helps open-source projects like Selenium continue to live on for the long-term)
  • Stop Inspecting, Start Glancing (by Dan Gilkerson, on automating web apps without looking at the DOM structure)
  • Transformative Culture (by Ashley Hunsberger, about moving from QA to Engineering Productivity and the culture changes necessary for getting better at testing)

Lessons from Timothy Ferriss’ “Tools of Titans”

Tools of Titans” is Timothy Ferriss‘ latest book, compiling lessons he has learned from interviewing over 200 world-class performers in his ‘The Tim Ferriss Show’ podcast. It is massive, and the number of takeaways he’s given away in the book is as plenty as it’s size. Like his “The 4-Hour Workweek” title, several of the ideas in it got me thinking deeper into how I’m living my own life, asking myself which projects and goals actually matter. Plus there’s bonus notes on other interesting things, like physical exercises that provide bang for the buck and the profound effects of using psychedelics in healthy doses.

Some favorite lessons:

  • The quality of your questions determines the quality of your life.
  • Do your kids remember you for being the best dad? Not the dad who gave them everything, but will they be able to tell you anything one day? Will they able to call you out of the blue, any day, no matter what? Are you the first person they want to ask for advice?
  • If you don’t do something well, don’t do it unless you want to spend the time to improve it.
  • Accept that quality long-term results require quality long-term focus. No emotion. No drama. No beating yourself up over small bumps in the road. Learn to enjoy and appreciate the process. This is especially important because you are going to spend far more time on the actual journey than with those all too brief moments of triumph at the end.
  • It’s not what you know, it’s what you do consistently.
  • When you’re thinking of how to make your business bigger, it’s tempting to try to think all the big thoughts, the world-changing, massive-action plans. But please know that it’s often the tiny details that really thrill someone enough to make them tell all their friends about you.
  • If this were the only thing I accomplished today, would I be satisfied with my day? Will moving this forward make all the other to-dos unimportant or easier to knock off later?
  • You can sacrifice quality for a great story.
  • People who have plenty of good ideas, if they’re telling you the truth, will say they have even more bad ideas. So the goal isn’t to get good ideas; the goal is to get bad ideas. Because once you get enough bad ideas, then some good ones have to show up.
  • The way you teach your kids to solve interesting problems is to give them interesting problems to solve. And then, don’t criticize them when they fail. Because kids aren’t stupid. If they get in trouble every time they try to solve an interesting problem, they’ll just go back to getting an A by memorizing what’s in the textbook.
  • Commit, within financial reason, to action instead of theory. Learn to confront the challenges of the real world, rather than resort to the protective womb of academia. You can control most of the risks, and you can’t imagine the rewards.
  • Choose projects and habits that, even if they result in “failures” in the eyes of the outside world, give you transferable skills or relationships.
  • For anything important, you don’t find time. It’s only real if it’s on the calendar.
  • When deciding whether to commit to something, if I feel anything less than “Wow! That would be amazing! Absolutely! Hell yeah!”—then my answer is no. When you say no to most things, you leave room in your life to really throw yourself completely into that rare thing that makes you say, “HELL YEAH!”
  • Great creative work isn’t possible if you’re trying to piece together 30 minutes here and 45 minutes there. Large, uninterrupted blocks of time—3 to 5 hours minimum—create the space needed to find and connect the dots. And one block per week isn’t enough. There has to be enough slack in the system for multi-day, CPU-intensive synthesis. For me, this means at least 3 to 4 mornings per week where I am in “maker” mode until at least 1 p.m.
  • Don’t try to please anyone but yourself. The second you start doing it for an audience, you’ve lost the long game because creating something that is rewarding and sustainable over the long run requires, most of all, keeping yourself excited about it. Trying to predict what an audience will] be interested in and kind of pretzeling yourself to fit those expectations, you soon begin to begrudge it and become embittered—and it begins to show in the work. It always, always shows in the work when you resent it.
  • You can’t blame your boss for not giving you the support you need. Plenty of people will say, ‘It’s my boss’s fault.’ No, it’s actually your fault because you haven’t educated him, you haven’t influenced him, you haven’t explained to him in a manner he understands why you need this support that you need. That’s extreme ownership. Own it all.
  • The world is this continually unfolding set of possibilities and opportunities, and the tricky thing about life is, on the one hand having the courage to enter into things that are unfamiliar, but also having the wisdom to stop exploring when you’ve found something worth sticking around for. That is true of a place, of a person, of a vocation. Balancing those two things—the courage of exploring and the commitment to staying—and getting the ratio right is very hard.
  • Any great idea that’s significant, that’s worth doing, for him, will last about 5 years, from the time he thinks of it, to the time he stops thinking about it. And if you think of it in terms of 5-year projects, you can count those off on a couple hands, even if you’re young.
  • The way you do anything is the way you do everything.
  • To blame someone for not understanding you fully is deeply unfair because, first of all, we don’t understand ourselves, and even if we do understand ourselves, we have such a hard time communicating ourselves to other people. Therefore, to be furious and enraged and bitter that people don’t get all of who we are is a really a cruel piece of immaturity.
  • It’s better to be in an expanding world and not quite in exactly the right field, than to be in a contracting world where peoples’ worst behavior comes out.
  • In any situation in life, you only have three options. You always have three options. You can change it, you can accept it, or you can leave it. What is not a good option is to sit around wishing you would change it but not changing it, wishing you would leave it but not leaving it, and not accepting it. It’s that struggle, that aversion, that is responsible for most of our misery.
  • Perhaps I didn’t need to keep grinding and building? Perhaps I needed more time and mobility, not more income? This made me think that maybe, just maybe, I could afford to be happy and not just “successful.”

Playing with Excel Files in Ruby Using Roo and Write_XLSX

Because of a small tool pitch I gave to our technical writer, I had a chance to play with Excel files through code for several hours last week. I have not done that before, but I felt that it was a pretty easy enough challenge as I have worked with CSV files in the past and thought that the experience would be something similar. I knew I just have to find out what existing libraries I could take advantage in order to build what I thought the program should be capable of doing, which is basically reading two Excel files, comparing them, and creating a new file with updated data based on both files.

Some googling brought me to the ruby gems Roo and Write_XLSX.

Roo helped with reading Excel files, and we can do this by:

xlsx = Roo::Spreadsheet.open(FILE_PATH)
xlsx = Roo::Excelx.new(xlsx)
spreadsheet = xlsx.sheet(SHEET_NUMBER)

Once we have access to a desired Excel file, we can get whatever data we need from it:

spreadsheet.each(column_data_1: COLUMN_NAME_1) do |info|
    // do something with information
end

After that, it’s just a matter of what information do we want to retrieve and manipulate from desired files. I mostly like to use arrays and hashes from here on.

As for creating new Excel files, we can use write_xlsx:

workbook = WriteXLSX.new(FILE_PATH)
worksheet = workbook.add_worksheet
worksheet.write(ROW_NUMBER, COLUMN_NUMBER, INFORMATION)
workbook.close

These two libraries can actually do more. Roo has an interesting read/write access with Google spreadsheets using roo-google. Write_XLSX on the other hand have formatting features we can leverage for better looking Excel outputs. I didn’t have to use those functionalies for the current test project though so I’ll leave those for another time.