For work reasons, I’ve recently become interested in resources for those new to line management. I put out an appeal for suggestions on Twitter and Managing The Unmanageable was recommended by Thomas Ponnet, with a little cautious reservation:
@qahiccupps Hope you enjoy it. I don’t agree with everything but that comes with the job description. Not all translates for my context.
— Thomas Ponnet (@ThomasPonnet) August 15, 2016
This quote from the book’s preface sets up the authors’ intent nicely:
There is no methodology for the newly anointed development manager charged with managing, leading, guiding, and reviewing the performance of a team of programmers — often, the team he was on just days before. There are no off-the-shelf approaches. Unlike project managers, who devote hours and hours of study toward certifcation in their chosen career path, development managers often win their management roles primarily from having been stellar coders while displaying a modicum of people skills.
The book is long – over-long for my taste – and, rather than try to rehash the whole thing, I’ll take the liberty of making an exceedingly crude precis:
- people are all different
- … but there are broad classes of characteristics that it can useful to acknowledge and look for
- people are motivated by a relatively small set of important things
- .. and, after a certain level is reached, salary is not usually the most important thing
- hiring well is crucial, and can be extremely difficult
- … and a manager should be thinking about it even when they are not actively hiring
- to do well, a manager needs to be organised
- … even more organised than you probably think
- to command respect from a team, a manager should be able to demonstrate relevant skills
- … and need to know when is a good time to do that and when to step back
- to enjoy the support of a team, a manager needs to show empathy and give protection
- … and that sometimes means letting them fail; but shouldn’t mean setting them up to fail
- to function well within a company a manager needs to establish relationships and communicate well
- … in all directions: down, up, and across, and in different media
- a good manager will reflect on their own actions
- … and look to improve themselves
- the source of a team culture is the manager
- … and, once established, it requires nurturing
Perhaps these things seem self-evident. Perhaps some of them are self-evident. Broadly speaking I think I’d agree with them, based on my own experience. And, in my own experience I find that I learned many of them only incrementally and some of them the hard way.
Which is where a book like this can help – it’s a brain dump of wisdom from the two authors mostly, but also from a bunch of others who offer nugget-sized bites of experience such as
Managers must manage – Andy Grove
with associated commentary:
I’ve used Andy Grove’s phrase innumerable times to coach my managers and directors of programming teams. When confronted with a problem, they can’t just “raise a red ﬂag.” I’m always available when needed, but good software managers find ways to solve problems without my involvement or executive management direction.
And here’s handful of others that chimed with me:
Don’t let the day-to-day eat you up – David Dibble
David made this statement to make the point to his management team that managers have “real” work to do; that the seemingly urgent—e-mail, meetings, the routine—could easily fill a day. Only by being intentional about how we use our days can managers overcome letting that happen
If you’re a people manager, your people are far more important than anything else you’re working on – Tim Swihart
Tim notes, “If a team member drops by at an awkward time and wants to chat, set aside what you’re doing and pay attention. They may be building up the courage to tell you something big. I’ve noticed this to be especially true when the sudden chatter isn’t somebody who normally drops by for idle conversation.”
Managers who use one-on-one meetings consistently fnd them one of the most eﬀective and productive uses of their management time – Johanna Rothman and Esther Derby
The statement is a match for our own experience.
We have two ears and one mouth. Use them in this ratio – Kimberly Wiefling
While I love theory and can happily spend time in talking shops, dissecting semantics and splitting hairs, as my recent MEWT experience showed …
— Iain McCowatt (@imccowatt) April 9, 2016
… I also recognise the value of activity to explore, inform, test, and back up the theory. I like to think of myself, still, as a practitioner, and Managing the Unmanageable is a book written by practitioners and grounded in their practice, with examples drawn liberally from it.
It’s unlikely, as Thomas Ponnet suggested, and I’d agree, to fit exactly with everything that you’re doing right now with the team you have in the place you’re working – especially as some of it is very specific to managing software developers. Parts of it will probably jar too. For instance, I found the suggested approach to levels of seniority too simplistic.
But what it can do is give you another perspective, or inspiration, or perhaps fire warning shots across your bow from some position not too dissimilar to yours, and rooted in the real world of managing people in technical disciplines.
ובכן – לא.
הכלים האלה, בסופו של יום, מוגבלים. אולי מדובר במשהו שפשוט נמצא מחוץ לגבולות הגזרה של הכלי (Ready! API לא מיועד לאוטומציה של דפדפנים, למשל, וטסטים לא מתעסק בשום דבר מחוץ לדפדפן), או שסתם מדובר בנושא שהכלי לא טוב בו במיוחד. אבל עם הכלים הנוצצים והחזקים שיש היום בשוק – קשה יותר לבנות טיעון נגד הסתמכות על הכלי, וחברות רבות עשויות להסתפק בבדיקות סוג ב’, כי למה להתחיל ולבנות פרוייקט תכנותי מורכב שצריך לתחזק מרמת התשתיות ומעלה, כשכל מה שצריך לעשות הוא להריץ את הכלי הנפלא שקנינו – ובדרך כלל אפשר גם להריץ אותו משורת הפקודה? וזה שצריך להגדיר את הכלי בנפרד משאר המוצר? בסדר, פעם ב… יגיע אחד הבודקים ויסדר את התרחישים המורצים, או ישנה את הפרמטרים שנשלחים אליהם. אז זה קצת מציק. אז מה? בשביל זה לשלם לבודק שיודע לתכנת?
חוץ מזה – כאשר משתמשים בכלי כולל שכזה, לא באמת יודעים מה קורה מתחת למכסה המנוע. ואז, אם פתאום משהו לא עובד – אין לאף אחד את היכולת לחטט פנימה ולתקן את הבעיה, כך שצריך להסתמך על התמיכה של מי שמייצר את הכלי.
וכמו באופניים חשמליים – מדי פעם נופלים. לפעמים קורה מקרה ומגלים שהכלי כבר לא מספק את צרכי הארגון – כי הארגון השתנה, או שצורכי הבדיקות גדלו. במקרה כזה, המחיר המושקע בכלי עלול להיות גבוה מאוד – ועלות המעבר גבוהה אפילו יותר.
ונקודת דמיון אחרונה ששמתי לב אליה תוך כדי כתיבה – רוכבי אופניים רגילים נוטים להסתכל על רוכבי האופניים החשמליים בבוז מסויים, או אולי מדוייק יותר לומר – בהתנשאות. זה לא משנה שהם עצמם יכולים לתאר כמה וכמה מקרים בהם אופניים חשמליים הם הבחירה הנכונה (למשל – “אין לי מקלחת בעבודה”), תחושת ההתנשאות עדיין קיימת.
הדבר דומה לגבי כתיבת אוטומציה ללא תכנות – למרות שאני, כבודק שמתכנת, יכול לתאר כמה תרחישים בהם הבחירה הנכונה היא להשתמש בכלי מוכן מראש, עדיין, אני מרגיש את אותו דחף מתנשא כשאני שומע על מישהו שמבסס את הבדיקות האוטומטיות שלו על כלי שכזה.
In theory – Electric bike is a great idea. It’s relatively cheap, relatively eco-friendly, and does not involve all of that sweating and effort that prevents people from using it as a transportation vessel for short & medium ranges. Riding a bike saves time for just about every ride inside a city, reduces traffic jams (or at least, mostly unaffected by it) and is generally fun. Unless rain is a problem for you – there are not that many reasons not to use it. You don’t even need a driving license for it.
However, in practice (at least here in Israel), the reality is quite different – a combination of poor infrastructure and some other factors (such as the young age of many electro-cyclists), results in cyclists terrorizing pedestrians, and being involved in an unproportional amount of accidents that are not as common with regular cyclists (I didn’t manage to find official figures, but the numbers I’ve seen while searching were around 2 injured people per day during 2014, including pedestrians that were run-over by an electric bike, while regular cyclists are mainly counted as “were hit by a car” and get to a bit less than one a day). But honestly – I am willing to believe just about any ridiculously high number I might hear, since I see how electric cars are being used. I’ve seen electro-cyclists ride with their eyes in their phone (held in one hand), riding in couples or even triplets, or folding a leg beneath the rider, and even one time I saw a rider with both legs on the top tube (The phone, naturally, was in one hand).
Each and every time I see such a thing I ask myself “why are they doing that?” And each and every time I answer “because they can”. While using the pedals, there are a lot of forces moving in many directions – were I to look at my phone while on my bike, It would take me less than 10 seconds to fall to the ground. I must constantly look ahead to see if I will need to shift gears, and picking a friend on my bike will mean more effort for me. With electric bicycle, those “costs” are not really visible. People don’t have to be as attentive and as careful, they can reach a grater velocity without any effort, and they can get out with losing concentration for more than a couple of seconds.
That is, until one time they can’t. An accident caused by an inattentive electric rider is more likely to cause grater damage – It’s faster, heavier (if giving a friend a ride) and by the time the rider gets to the brakes, the accident has already happened.
Tools that are marketed under “the end to your automation problems” or “everything your automation needs” (not to mention “code-less automation) have finally reached the point where we can compare them to electric bike. When I first got to work, we were in the late phases of getting rid of a tool called “Badboy“, and it was fairly obvious why – It was a record & playback tool, that used it’s own proprietary browser to run. Anyone looking at it could tell that it might be a good time to hire someone who can do a better work. The tools wasn’t really bad, but it didn’t help with actual browser coverage, and most importantly – it was ugly and uncomfortable to use.
One the other hand, we can look at Testim.io – this is a newer record & playback tool, that works on chrome, looks nice and modern, and provides a bunch of useful things such as grouping actions for reuse, some strong built in validations, and a test report with images. A great time-saver. Working with such a tool, it’s not that easy to notice that we are missing stuff (the first thing that comes to mind is non-web stuff, such as database checks). And, if we move to some non-browser tools – we get an even more complete and powerful tool, such as Ready!API by SmartBear for SOAP\REST testing which provides, on top of DB checks and strong validations with a simple way to setup things (just add a WSDL, and you’re good to go) some neat capabilities such as automated security and load checks and even some simulation services that enables mocking (and controlling) the response for a request.
So, we’re making a great progress, right? We can leverage those tools to get rid of the infrastructure fuss and focus on creating checks. We don’t even need to know how to code. The best of all worlds!
Well… no. Not really.
Those tools, powerful as they might seem, are pretty limited. It might be because GUI is not really suitable for programming complicated logic, or simply a limitation of the tool’s scope (Browser testing, for instance, is out of scope for Ready!API). But with the shiny tools out there today, it’s getting more and more difficult to build a case against using them, or for migrating out, because we do gain a lot out of them. So why should a company invest in building an extendable, tailored test harness, when we can get all of those cool things for the price of using a tool? Most tools can even be run from the command line, and thus integrate into our CI. And the fact that the tool is configured outside of the main product’s code? that’s fine. Every now and then we’ll just have a tester go and update the scenario parameters. for that small nuisance, why should we pay for testers that can code?
Besides, when using a tool, there’s only so much you can know about the tool’s internals and what’s actually going on in your tests – and if something isn’t working, you can’t just peek under the hood and fix it – you have to contact the vendor support (or, if it’s an open source tool – you can start diving into the code and compile your own version of it, and it will be quite painful to do).
Also, to return to our bicycle analogy – it’s great to ride while using the phone and zooming around, and you will normally stay out of trouble – until suddenly, you don’t. If you get to a conclusion that the tool you’re using is no longer doing the work you need – it will be that much harder to migrate out of it, and to develop all those nice capabilities you’ve grown accustomed to in your framework.
And, one last point of similarity I found while writing this blog – regular bicycle riders tend to sneer and look down at electric cyclists. They can come up with several scenarios where using them is an acceptable choice (for instance “I don’t have a shower at work” is an acceptable excuse), but every time I see someone riding an electric bike I get that feeling of moral superiority. I’ve noticed pretty much the same feeling towards tool users – despite the fact that I can describe several scenarios where using a tool is better than writing everything at home – as a tester who codes, I can’t help it but look down on testers who automate without coding.
On levels of understanding of systems:
Technology very broadly is becoming more and more complicated … actually so complex that no one, whether you’re an expert or otherwise, fully understands these things … They have enormous number of parts that are all interacting in highly nonlinear ways that are subject to emerging phenomena.
We’re going to have bugs and glitches and failures. And if we think we understand these things well and we don’t, there’s going to be tons of gap between how we think we understand the system and how it actually does behave.
On modelling reality with a system and then creating a model of that system:
… the world is messy and complex. Therefore, often, in order to capture all that messiness and complexity, you need a system that effectively is often of equal level of messiness and complexity … whether or not it’s explicitly including all the rules and exceptions and kind of the edge cases, or a system that learns these kinds of things in some sort of probabilistic, counterintuitive manner.
It might be hard to understand all the logic in [a] machine learning system, but it still captures a lot of that messiness. I think you can see the situation where in machine learning, the learning algorithm might be fairly understandable. But then the end result … You might be able to say, theoretically, I can step through the mathematical logic in each individual piece of the resulting system, but effectively there’s no way to really understand what’s going on.
On “physics” and “biological” thinking:
[Physics:] A simple set of equations explains a whole host of phenomena. So you write some equations to explain gravity, and it can explain everything from the orbits, the planets, the nature of the tides … It has this incredibly explanatory power. It might not explain every detail, but it maybe it could explain the vast majority of what’s going on within a system. That’s the physics. The physics thinking approach, abstracting away details, deals with some very powerful insights.
[Biology:] Which is the recognition that oftentimes … the details not only are fun and enjoyable to focus on, but they’re also extremely important. They might even actually make up the majority of the kinds of behavior that the system can exhibit. Therefore, if you sweep away the details and you try to create this abstracted notion of the system, you’re actually missing the majority of what is going on.
Oftentimes I think people in their haste to understand technology … because technologies are engineered things … think of them as perhaps being more the physics thinking side of the spectrum.
There’s this idea within complexity science … “robust yet fragile,” and the idea behind this is that a lot of these very complex systems are highly robust. They’ve been tested thoroughly. They had a lot of edge cases and exceptions built in and baked into the system. They’re robust to an enormously large set of things but oftentimes, they’re only the set of things that have been anticipated by the engineers. However, they’re actually quite fragile to the unanticipated situations.
TL;DR This post is my report on Testival 2016 that was held last weekend in Rijeka STEPRI center. First, a few metrics. We had in total 32 participants, with female/male ratio 12/20! As this is free event, dropout count is important metrics for us. 15 registered testers did not show, and did not let … Continue reading Report on Testival 2016 →
This will be a short blog post – shorter than my usual posts anyway.I’m excited about some things. First, work is great. They day job has the usual interesting challenges and problems that any day job has. The team I am working with though is great and…
TL;DR This blog post will explain how to get full exception stack trace during the gunicorn start up issue. gunicorn is python native application server for running django application. So you changed something in your django settings.py configuration, and gunicorn failed to start. In my case, I did not get full exception stack trace, which … Continue reading How to get full stack trace during gunicorn exception investigation →
The Test team book club at Linguamatics is currently reading What Did You Say? The Art of Giving and Receiving Feedback. Here’s a couple of quotes that I picked out for our last session:
- If you’re really interested in helping people, you’ll do well to start your feedback by opening your own motives to inspection.
- Even when it’s given at the receiver’s request, feedback describes the giver more than the receiver.
- When the data and their model don’t match, most people discard the data.
I recall an instance when, engaged in discussion with a colleague I’ll call Russell, about the data analysis he was presenting, I spotted an opportunity to offer feedback. It was about something that I knew Russell wanted to change. It was about something that I knew was open to me to give feedback on, because we had talked about it. It was about something that I thought would be beneficial for Russell in multiple ways and, I hoped, would provide some insight into a particular behaviour pattern that he had.
However, it was also the first time that I had seen this particular thing. A data set of size one. I had no evidence, yet, that it would lead to the end point that Russell desired to alter. A data set of size zero.
Against this: my instinct, my gut, and my experience. And a sense of goodwill, built up over time, over repeated interactions, over sometimes difficult sessions where I had tried to demonstrate that I do care to assist and support and advise because I want to help Russell to be the best he can be, in the respects that matter to him and for his work.
But I was still cautious. I have unwittingly burned and been burned enough times over the years to know that each of these conversations carries with it risks. Risks of misreading the context, risks of misreading the agreements, risks of misreading the mood, risks, risks, risks, …
But I went ahead anyway. The potential benefit and the goodwill in the bank outweighed the risks, I calculated, on this occasion. And I gave my feedback. And Russell agreed with me. And I breathed a deep internal sigh of relief.
Comparing this anecdote to the quotes I pulled from the book:
- My motives, I think, were good: I wanted to help Russell achieve a personal goal.
- But the feedback does reflect something about me: an interest in reducing unnecessary complexity, an interest in making presentation clear, the ego that is required to believe that my colleagues will want to listen to any advice from me, …
- In this case, it turned out my suggestion didn’t contradict Russell’s model but exposed it, and in any case I had little concrete data to present.
I use this episode as an example not because it ended well, particularly, but because it’s an illustration for me of how much I have been influenced by What Did You Say? in the couple of years since I first read it. I consciously I go about my day-to-day business, doing my best to be careful about when I choose to offer feedback, about when I deliberately choose not to, and about picking up and picking up on any feedback that’s coming my way in return.
I try to treat this as a testing task where I can, in the sense that I try hard to observe my own actions and the responses they generate, and I think about ways in which they might be related and how I might approach things differently in the next exchange, or at another time, with this person, or someone else.
Easier said than done, of course, so I’ll finish with another quote from the book, another quote that I’ve taken to heart and act on, that regularly helps guide me with pretty much everything that I’ve said above:
Don’t concentrate on giving feedback; concentrate on being congruent–responding to the other person, to yourself, and to the here-and-now situation. Don’t go around hunting for opportunities to give feedback, because feedback is effective only when the need arises naturally out of congruent interactions.
Some details have been changed.
Imposter syndrome is common in the software industry and it’s not unique to developers. It’s exciting to be in an industry that is evolving and changing so quickly. It’s hard though when you do plug-in and feel the sheer volume of blogs, books, webinars, training, open source projects, the list is never ending. I have … [Read more…]
In this post I will present a UX issue from a very famous engineer cultured company. Every user interface should be developed in such manner that it is self descriptive. It should be self documented, so menu items or input fields should have labels that clearly describe their purpose. Tooltips must not be some fancy technology, but … Continue reading Android back arrow icon UX issue →
(English first, as this is also a response to a source whose owner probably does not speak Hebrew)
I’m assuming you have at least heard of Gem Hill’s podcast let’s talk about tests baby and if you didn’t, go and listen to a few episodes – they are short and I usually find them interesting. I’ve listened to the episode on using selenium IDE. It just so happens that on the same day I’ve listened to it, I also attended a local selenium meetup (which, in case you live in Israel, or just happen to be in the neighborhood when one is occurring, can be found here) and after the meetup a few of us grabbed a cup of coffee (tea in my case) and continued to chat for a bit. One of the subjects that came up during this chat was about record and playback tools. If you’ve read this post you can probably guess that I feel very strongly against this kind of tools.
Listening to Gem’s podcast, I noted that I was listening to the rare occasion where the person using selenium IDE1 is doing it properly with the right goals in mind – create a base, use the recording to flesh out some crude scaffolding quickly and then go and fix the generated code. Then, after the chat I had following the meetup, I thought about it a bit more, and realized I don’t like selenium IDE even when it’s used responsibly (Though, if I understood correctly, Gem’s done it right – use once or twice to bootstrap the code, then defenestrate).
Why? Because it’s like riding with training wheels.
When I was young, like all of the kids around my age, I had a bicycle with training wheels, and I rode them around. At some point, came the time for me to remove them, and my father spent several hours running behind me, holding the bicycle rack and releasing it when I wasn’t noticing. If you’ve been anywhere near bicycles lately, you probably know that the new fashion on teaching kinds to ride is by having them ride a balance bike – the reason is simple: When using training wheels the kid might get used to using the pedals and the breaks, but will miss the most important thing – learning to self balance on the bicycle. You also acquire some bad habits you will need to get rid of when you’ll later learn to properly ride a bike (for instance, the way you turn around is completely different). Finally, removing the training wheels is quite scary.
The same is true for using selenium IDE – it helps you do something that looks a lot like writing an automated check, and using it you are able to get some results that are (at least at the beginning) better than not using it, but by using it, you are missing the central skill that is required to write decent automated checks – which is the ability to think in algorithms and organize code in a reasonable way. And just like training wheels, it can be very scary to let go of it. Worse – using it as a learning tool leads to learning some bad habits – such as having each script live in it’s own world, initialize everything for itself and so on. In fact, if we were to convert a recorded script to fit into a proper test infrastructure, not a single line of code will remain – initialization and teardown code will be in the superclass, every selenium code will be in the page-objects, and chances are that even page-objects will be hidden beneath another abstraction level. A bad habit that is a bit harder to shrug off is that by using Selenium IDE we are getting used to try and mimic human actions with our automation and completely ignore the fact that humans and computers are different – and things that are easy for a human being are sometimes difficult, or impossible, for a computer – and vice versa. In addition, recorded scripts are usually quite meaningless in terms of what they actually validate.
So, what should we do? To answer that I want to go back to my bicycle example – How do I like to teach riding a bicycle? I got to do that several times in the past – teaching my cousins, and a couple of friends closer to my age that managed to grow up without learning to ride. What I did was to start from the running point, but instead of holding the bicycle from behind, I run side by side with them, holding them by the shoulder and balancing them until they start doing that themselves. It takes about two hours of doing that before they can ride without my help, and then we go on to the more complicated parts of getting on and off the bike. All in all, after four hours of training, we can ride side by side for a short trip. An equivalent behavior will be learning with a mentor – strong style pairing seems to fit well this image, assuming that there is some basic coding knowledge to begin with (otherwise, focusing on at least some basic coding skills should be the first thing to learn). Lacking a mentor around, I guess you could start by copying some template of “how to write a selenium test in language X” from an online tutorial (there are dozens of them). Though, if you don’t have a mentor available to help you, feel free to send me a message (there should be a “contact me” form on the left, or you could leave here a comment) and I’ll try to help you getting started – though if you are using a language I’m not familiar with, my help will be limited.
1 Just one note – I use here “selenium IDE” quite often, but if you are actually using selenium IDE, you might want to check out “Selenium Builder”, since IDE is planned to reach end-of-life for at least 3 years now. ↩
אותו הדבר נכון לגבי סלניום IDE – הקלטה עוזרת לכתוב משהו שנראה כמו בדיקה אוטומטית, והתוצאות שמשיגים בעזרת הכלי הזה עדיפות (לפחות בתחילת הדרך) על התוצאות שניתן להשיג בלעדיו. אבל שימוש בכלי הזה מדלג על הכישור הכי חשוב כדי ליצור בדיקות אוטומטיות – היכולת לחשוב על אלגוריתם ולארגן קוד בצורה פחות או יותר הגיונית. בדיוק כמו גלגלי עזר, גם על סלניום IDE מפחיד לוותר, וגרוע יותר – רוכשים כמה הרגלים מגונים דרך שימוש בכלי הזה, כמו למשל העובדה שכל סקריפט מוקלט מבצע את פעולות האתחול בעצמו וחי בעולם משלו במקום שקוד האתחול ישב במקום אחד מסודר. למעשה, אם ממירים קוד מוקלט לתוך פרוייקט בו התשתיות מסודרות היטב, לא תישאר שורה אחת מתוך הסקריפט המקורי – קוד האתחול והניקיון אחרי הבדיקה יהיו במחלקה ממנה יורשת מחלקת הבדיקה, קוד סלניום יעבור לתוך page-objects (שבעצמם יהיו חבויים בתוך שכבת אבסטרקציה) ומהבדיקה המקורית לא נשאר כבר כלום. הרגל מגונה שקשה יותר להיפטר ממנו הוא שכלי הקלטה נוטים להרגיל אותנו לחקות פעולות משתמש בעזרת הקוד שלנו ולהתעלם מכך שיש דברים שנכון יותר לעשות אחרת בעזרת מחשב. חוץ מזה, בדיקות שנכתבות בעזרת כלי הקלטה נוטות להיות שטחיות וחסרות שיניים בהשוואה לבדיקות שנכתבו ע”י קוד ויכולות להסתכל על דברים שקורים מחוץ לדפדפן (כמו למשל מסד הנתונים).
אז, מה עושים? לבד זה מפחיד, וגלגלי עזר הם לא פתרון טוב.
כדי לענות על זה אני רוצה לחזור למשל האופניים, ולספר איך אני מלמד לרכוב (אני לא עושה את זה באופן מקצועי במיוחד, אבל יצא לי ללמד כמה בני דודים בגיל הנכון, וכמה חברים בני גילי שהצליחו לגדול בלי ללמוד לרכוב) – אנחנו מתחילים קודם כל מהשלב בו אני רץ לידם (לא מאחור, ליד) ומחזיק אותם בכתפיים כדי לאזן אותם עד שיוכלו לעשות את זה בעצמם. בערך אחרי שעתיים הם מגיעים לנקודה בה הם מסוגלים לרכוב בלעדי, ואז אפשר להתחיל לטפל בנקודות הקשות יותר של לעלות על האופניים ולרדת מהם. בסך הכל, אחרי כארבע שעות (על פני שני מפגשים) אנחנו כבר מסוגלים לרכוב יחד לטיול קצר. המקבילה של זה בעולם התכנות היא עבודה עם מדריך אישי, והרעיון של strong style pairing נראה לי מתאים במיוחד, אם יש ידע כלשהו בתכנות שאפשר לבנות עליו. אם אין ידע כזה, אגב, לרכוש אותו יהיה הצעד הראשון שצריך לעשות בכל מקרה – אין משמעות לשימוש בכלי הקלטה לצורכי לימוד אם אי אפשר להבין את התוצרים של הכלי הזה מספיק כדי לשפר אותם. בהיעדר מדריך זמין, אני מניח שאפשר להסתכל על אחד המדריכים ל”איך לכתוב סלניום בשפה X” באינטרנט (יש לא מעט מהם בחוץ, ואני מחבב את האתר של יוני פלנר שמכיל מדריכים בלא מעט שפות תכנות). אבל, אם אין אף אחד שידריך אתכם, אתם מוזמנים להשתמש בטופס הפנייה שנמצא משמאל, או להשאיר כאן הודעה ואשמח לנסות לעזור לכם להתחיל.