Thursday, February 6, 2020

ETC 2020 - day 0


So, after landing yesterday in Amsterdam, I used most of the day before ETC is starting to tour in some of the fishing villages around. That, at least, was the plan. At the hotel I was told that there's a hop-on hop-off bus I could take from central station, and so I went there, looked for the relevant booth and found out that this is true only during summer. Ah, well, I'll take a regular bus, the helpful man at the counter told me I could find tickets at the EBS office just on the other side of the central station.  So I went looking for it. about an hour later, I realized I have no idea where's that and went back to the info booth to ask for more specific directions (as no-one was familiar with the name I was given). It appears that the EBS is inside the train office, and so I managed to purchase a bus ticket - which in turn led to me looking for the bus. It took me a while to figure out that they were hiding hte buses on the 2nd floor, up the stairs. And finally, I was out to Volendam (which, as one can guess from the massive wooden stakes in the picture, is suffering from a grave problem of giant vampires). The village itself is a nice place to walk about, and the scenery is lovely and very calming. I took a ferry to Marken, and from there back to Amsterdam.
Then, after a quick shower (and time to recharge my phone's battery, that was depleting quite rapidly), down to the lobby and out to the pre-conference meetup, I met Marianne on my way down, and we met with more people in the Lobby (Joep, Elizabeth  and Marit) and most of us set out to the meetup venue at one of the ING buildings. At the meetup itself I met a lot of people I've met before, and some new people as well, but listing their names would be testing my memory a bit too much, so I'll just say that I got to meet Gem Hill, for the first time, and talk again shortly with Thomas, and that there was a nice talk given by Lisa Crispin and Janet Gregory, and that Maaret facilitated a very interesting discussion, and that I heard some horror stories from Fiona Charles with regards to disfunctional workplaces, as well as an interesting tip for the daily stand-up: come prepared. I wonder whether my team will buy into this one for an experiment, as we are having trouble just in keeping the stand-ups in time (Hi team! how are things back at home?), it feels like something worth trying.

All in all, I had  a really nice day, can't wait for the conference to start tomorrow.

Tuesday, January 7, 2020

Why don't I like python?



Some of you might have noticed that over the past 9 months I've been tweeting a bit under the hashtag #PythonSucks. As part of my pains with this language I asked the twitterverse to help me with finding sources that can confirm (or debuff) the claim I've been hearing a lot about python contributing to developers' productivity (for an example of this boast check this almost 5 y.o. podcast episode, around minute 11:30). During the conversation that sprung up from this question, Maaret mentioned it will be nice to see what am I missing when working with python.

As I went on to start answer, I figured out I have a bit more than a tweet's content to say about it - and so, this post is on. Some of the things I dislike about python are probably due to its nature as a dynamically typed language (I don't have a lot of experience in other languages that share this property, so I'm comparing it mainly against java and c# which are the closest statically typed languages (unlike c++ or c which are a bit more low-level)

So, what is it I don't like about python?

  • It's chaos prone.
    While it's definitely possible to write bad code in just about any language, my feeling is that in python writing well structured code is an extra chore. There are "type hints" that allow me to state "this variable should be of this type", but it is only optional, so we need to remind people to do this. It is possible to put multiple classes inside a "module", so we have to take care and ensure that the files are not growing out of proportion. The lack of the "private" concept is pushing people to abuse python features (check "name mangling") and instead a coding convention was invented to indicate "this should be private"  I also want to smear the variable scoping, but I'm not sure I understand it enough to do that.
    Under the mantle of "consenting adults" the language is allowing too much freedom and entrusting the programmer with the quite heavy task of keeping everything tidy with no purpose other than tidiness. Another example is the stupid decision in holy PEP8 (python coding style) with regards to string quotes (use single or double quote?): "Pick a rule and stick to it." Really? 
  • Tooling support sucks.
    Don't get me wrong here. I am rooting for my favorite python IDE (I use PyCharm) which saves me a lot of effort and is making everything less painful. Still, even with my limited use of the language, I found some stuff I was missing comparing with my favorite java IDE by the same vendor (IntelliJ) - since stuff is dynamically typed, auto-complete is weaker (type hinting helps, where it exists), the same property is probably why I spent several hours looking for a "generate equals and hashcode" functionality that was built-in in IntelliJ but missing from PyCharm - it is simply more difficult to do if there isn't a defined set of fields. Another thing that works less well is finding usage of a function, and I'm sure there's more. The tool vendors just have less metadata to work with
  • It's difficult to read.
    No, I'm not speaking only on the lack of curly brackets and reliance on indentation (there's a reason why whitespaces are ignored in most other languages - they are invisible!) I'm speaking on what seems to me like favoring writing code over reading it. It starts with the odd ternary operator ("a=c if bool else d" is done in  most other languages I could find as "a= bool? c:d" where we first inform the reader that this is a question) goes on with convenient to use but meaningless constructs such as for\while: ... else: (what does it mean to have an "else" statement on a loop? ) and goes on with removing the most useful metadata - types being send and returned. Sure, one can put type hints, or have this information in the docstring, but as we all know - documentation gets out of sync with the code very fast). So sure - I might have less lines to read per function, but I'll be forced to hop into all of the functions I'm calling just to see what am I getting from them.  Personally, I also don't like the convention of using less braces (my IDE yells at me if I write "if (a>b):" and would rather have me write "if a>b")
  • Libraries are difficult to use.
    Sure, another of pythonistas boasts that I've encountered is that python libraries have great documentation. While this might be true, I prefer not needing to read the documentation except for finding about corner cases or difficult to explain stuff. It's those missing types again. The only way know that the parameter "X" is supposed to be duck-typed as a string is to read something outside of the code (I have not encountered a library that used type-hinting, I assume they are some). There's a very popular way of sending parameters as "args, kwargs", which means that just to find the names of the possible parameters I'll have to step outside of the code.  
  • Importing a file executes it.
    I don't think I need to add here anything. 
  • Dependency management?
    This one is probably just something I need to learn, but I haven't found out yet a too to help me with dependency management (such as maven or Gradle in Java).
  • It's a special bloody snowflake.
    It might just be my feeling, but sometimes I can just stare at the code and wonder what have the designers of a specific language quirk been thinking (oh, who am I kidding, I'm always blaming that Guido chap). We've discussed above the ternary operator, there's the odd choice of not including a "switch\case" support in the language, having "join" as a method of String instead of a method of the collection, and a plethora of tiny things I encounter but cannot recall at the moment). It seems that python just wants to be different than other languages just because, and I prefer things that stick to the convention unless there's a reason not to. 
  • Say "pythonic" one more time...
    Seriously, are we professional coders or a part of a religious cult? While this can be used to improve code aesthetics  I've seen this argument used to justify ugly code ("It's more 'pythonic' that way ").  
Those are the pain points I think are most visible to me at the moment, and from the technical point of view, I  don't think adding more would help. 
There is, however, one other property I really don't like - It's too easy to learn. 
Normally, you could think that being easy to learn is a good thing, but what actually happens in python is that the learning curve is longer. Yes, it is less steep, but on java or c#, once you are able to write a small scale exercise you have already faced some OOP principles (in fact, since every variable has an explicit type, the new coder must have faced this concept), in python, stuff just work without trying. In some manner, python is suffering from the same problem as the testing profession - it is really easy to get started with limited professional capacity, so people just assume it's easy and don't invest the further effort required to be good at what they do. 
Another part of that is that you could write some bad code and it will work and will be enough for quite a while. It makes python a great tool for non-programmers (such as data scientists who just need their script to work while they focus on honing their data science skills. a lightweight scripting language with extensive libraries is exactly what they need), but for me it only means that once you'll find that you are missing those extra bits of information to manage your project properly, you'll have a lot more to rewrite. 

Sunday, November 3, 2019

Book review - Social Engineering: The Art of Human Hacking



"Sir, you can't board this train with your bicycle"
I faced this statement (or something that conveyed its message in different wording, the translation from Hebrew isn't exact) from a train employee a while ago. As luck would have it, I was just listening to Christopher Hadnagy's "Social Engineering: The Art of Human Hacking", and thus went on to try and board the outcome - I burdened the employee with a barrage of accusations, making him responsible for my situation ("You're stranding me here at the airport after I bought a ticket and used it to get here to my connecting train", "what do you expect me to do now?"), claimed for precedence ("I've been boarding the train with my bike yesterday, and the day before", "why do you change the rules?") and applied time pressure ("Look, you are causing me to miss my train"). After a couple of minutes of arguing, he came to the conclusion that "If I can't see it, I can't stop you, if you would wrap it in your bike-case it's not my fault I didn't see it".
Ordinarily, I would have just thought it was me arguing and getting my way with it, but as you can see - I was employing several tactics to get what I wanted - I counted on the employee's empathy and the fact that he didn't want to be the bad person, added time pressure and offered an escape route that allowed him to save face in the form of "what if the bike had been covered?". I believe being aware of what I was doing helped me "win" this argument, and it sure did make me feel  uneasy a about how "evil" I was acting - consciously putting pressure on someone who was simply doing his job.

Since I neglected my blog for too long due to a multitude of things taking up my time and energy, I thought a good way to start writing again is with a task that have been waiting for quite a while now - a review of "Social Engineering: The Art of Human Hacking" by Christopher Hadnagy which is the first audiobook I listened to twice.

The first thing one should know about this book is that listening to it is a bit scary, as the book shows time and again how reasonable human behaviour can be (and is)  exploited to cause harm and then goes on to say "and were I a real malicious attacker, I would have take this to the next level by...". Apart from that, this book is a great first step in becoming a professional security engineer, and provides the next steps of practice in each step.
After listening to this book, there are two takeaways I continue with:
First - Regular, day-to-day human behaviour can be exploited in way most people don't imagine and leveraged in ways far more serious than one might expect.
Second - Despite the first point, defending against social engineering does not require behaving like a heartless automaton. Most of the times, it is enough to pause for thinking and double checking before acting.

In a nutshell - that's it. However, there's much more to this book, which is very well organised to topics.
First we start by trying to define social engineering, or SE, for short. This, perhaps, is the only place in the book where I think the author is not doing the reader justice. The book dwells on the rather blurry line between influencing a person for their own benefit (e.g. - convincing someone to quit smoking) and persuading them to act in favor of our own interest and against their own. The book claims a simple truth - the same skills and techniques used by malicious social engineers can be used in a variety of other, benevolent actors. A doctor will try to persuade their patients to take on healthier habits, a teacher will "educate" students and a friend might put some pressure on you to take that vacation you've been yammering on for ages. Still, in my eyes, the book is trying to paint a nice picture over a term that is used almost exclusively for actions that are, at least, unauthorized and most of the times - straight out malicious. The examples in the book in later chapters also fall in line with this approach and are portraying examples of misleading, putting pressure on people and in all ways get the upper hand of the victims.
Following on, the book goes on presenting the SE framework (more details can be found here) and the different skills and activities that comprise it.
First thing's first, the 2nd chapter is all about information gathering, showing how some trivial details can be used as a stepping stone to further attacks. For instance,knowing that someone is a stamp collection enthusiast is a good way to lure them to a malicious website claiming that you've inherited a stamp collection from your late grandfather and made a website with the stamps to be sold. Besides some examples on how destructive random bits of information can be in the wrong hands, the book mentions some tools such as BasKet and Dradis to organize the data, and points out to common sources of information - from social media and search engines to job adverts, whois registry, personal blogs and even simple physical reconnaissance and dumpster-diving (which, the book says, you should do with dark cloths and a good pair of boots). The chapter then goes on to the seemingly irrelevant topic of communication models, It's quite interesting, at least from the theoretical viewpoint, and it provides a nice way to break down any single social engineering "scene" (e.g. - sending a phishing email, having a conversation with a target), but it is not really a part of information gathering - a communication model can be used wen planning an information gathering strategy, but at the same time, it requires the information already gathered to succeed. Based on the Shannon-Weaver model of communication a social engineer can ask more specific questions: what is the type of feedback I want from the receiver? what sort of message would work best? what channel is the most effective way to communicate my message?

Next on the menu is the mysterious skill called "elicitation" and apparently that's a real word. Its meaning, in case that you are not familiar with it, is "drawing out". In our context, it's about drawing information out of our target. I assume that it can be used also to invoke an action (such as keeping one door open for a person, creating the expectation they'll hold the next door for you, which just happens to be the one you need a key card for) but the book does not dwell much on that aspect after mentioning that the goal of elicitation is to make the target take an action to the attacker's advantage - as small as answering a question or as big as providing access to a restricted area. The book lists some elicitation techniques, from simple ones that range between simply asking a direct question  and getting people tipsy and talkative to more elaborate schemes that may involve pretexting (see below) and preloading the target with information and emotions that will make them more susceptible to your suggestion.

I mentioned pretexting, right? because that's the topic of chapter 4.
A pretext, in laymen terms, is the image one projects about themselves. For instance, I go to work every day, carrying the pretext of a professional software tester. A social engineer might display pretexts that will mislead people - posing as an IT expert, as a worried father or as a pissed off customer. An important point this chapter makes: A pretext doesn't have to be a lie. In fact, it is much easier to pull of a pretext if you are using your own interests and knowledge as part of it. In fact, one of the dangers in pretexting is trying to pull off something completely foreign to you. For instance, I couldn't build, even in a month of intense research, the casual recall of events a soccer fan has experienced talked about dozens of times, so keep it simple and within your expertise. If you have to pretext as something you have no knowledge about - distance yourself. Communicate via e-mail, or on a short, carefully planned, phone call. It is also important to look the part - if you pose as the garbage disposal company representative, a company logo and a notebook will do wonders to your credibility. If you pretend to be a salesperson,  wearing a T-shirt is probably going to get you some unwanted attention.
No matter what you do, your pretext has to be carefully chosen and tailored to your needs and to the situation you're in.

The 5th chapter is all about magic.
Yes, yes, magic. Or at least as much magic as that possessed by a stage magician. If the skills up to this point were a calculated use of common human communication skills, now we are about to discuss some uncommon skills. Micro-expressions, for instance, are a very powerful way to detect how is a person feeling and quickly adapt your strategy if you aren't getting the reaction you were trying to get, but it is also a way to signal to the other person's subconsciousness without the filtering of the thinking facilities - a slight wrinkling of the nose will go unnoticed by many people, but they will still get an uneasy feeling.
Even more controversial than micro-expressions is the use of NLP, which, basically, is all about using side-channels. Regardless of whether you think NLP is a complete fraud or actual magic, There's no denying that NLP does provide extensive record of efforts to understand how human communication works, and that at least some of its methods are having some results. Sure, changing your tone of voice isn't going to magically make someone do your bidding, but it can divert attention and plant ideas. One "tool" I liked is labeled with the terrible title "The Human Buffer Overflow". Basically, it is directing the SE to rely on the automatic responses of people, and take advantage on social norms and expectations. If I helped someone with something, even if it's trivial, they will feel obligated to help me back. I'm unsure as to what exactly here is the so-called "buffer overflow", but I imagine that in order to be more effective, the SE can make sure to occupy the mind of the target with other things - a constant stream of talking, a difficult question, and so on. This way the mind will leave other tasks to the automatic part more easily.

The final chapter presenting the SE framework is about influence. After all, once we've gathered information and learned to control some neat tricks to elicit a response, it is time to cash in on our efforts and make people do what we want them to. Generally, the message is "know your goal, and improvise towards it". This, naturally, is a gross oversimplification - One does not "improvise", but rather builds a flexible plan, with options derived from the information gathered and constantly monitoring the target's response using the skills acquired and practiced ahead of time. The chapter discusses some important tools and principles, such as building rapport, constant monitoring, influence tactics and framing. Like most chapters, this one has a part that made me cringe a bit in discomfort. This one has a part about "manipulation". Unlike other types of influence, this is a direct attack against a person. It involves tips like "gain control over the target's environment" or "creating doubt", it does not shy away from "heavy intimidation", which is about making the target fear for physical harm or other "dire circumstances". In essence, this is the part people dislike the most about SE. The part which not only makes people behave the way the attacker wants, but may actually harm the target as a side-effect or even as a tactic. Being the pinnacle of the framework and cashing in on the previous ones, this chapters is quite long and full of interesting (and scary) techniques and stories.

The 7th chapter is about tools - everything from a lock-pick and business card to hidden cameras and software tools found in Trackback (The previous version of the Linux distribution now known as "Kali") very educational, and provides a lot of entry points to the different topics.

Of course, a book such as this won't be complete without an impressive list of case studies, demonstrating the wide range of possibilities - from the highly technical story of Kevin Mitnick hack of the DMV which involved breaking into the phone system and routing genuine calls of police officers calling the DMV to his own phone (thus collecting the necessary details to impersonate them later) which required deep knowledge of the phone routing system and of the identification process used by the DMV, and then some very convincing pretexting, to the simple case of a security tester who found a genuine hacker roaming through an unprotected server and then chatted using notepad until he got enough details to find the hacker offline. The stories are interesting by themselves, and each shows a different perspective demonstrates different skills and shows how they are applied in real world situations.

Scary, right? It seems that the smallest detail could be used to leverage more details and create an opening to an even wider attack, and most attacks simply rely on people acting as human beings. This is why the final chapter of the book is so important - how to prevent and mitigate attacks.
Like all defenses, it isn't perfect, but if being used properly, the techniques in this chapter could frustrate and exhaust someone trying to social engineer their way into your organization (or your private life, for that matter).
The easiest tip here is "keep your software updated". It might not be easy to implement, but it is a generally good rule to follow - updated software tends to have less known vulnerabilities, and thus prevent many software based attacks, so it won't matter if the SE managed to get you to open that PDF file.
The second is to teach yourself and your surrounding how to identify an attack - know what is generally possible (for instance, by reading this book) and how to identify the stupid kind of attacks of each vector. You might not be able to defend against someone calling and asking "can I have your email address? I want to send you details about the event I wish you would attend", but you'll be able to delete the obviously false "This file includes a debt you have not cleared, if you won't pay by next week, legal action shall be taken"
Another tool I find important enough to mention is developing scripts that allow you to stay kind without letting someone what they want: "I'm sorry, but our IT people don't allow external USBs, if you want to print a replacement to the paper ruined by your coffee, there's a printing service around the corner". Practicing situations and such scripts can help when facing a real SE attempt.

All in all, I highly recommend reading this book, in any format convenient for you .

Sunday, June 2, 2019

להתחיל במקום חדש



מצמצתי לרגע, ועברו חודשיים. 
לפני חודשיים (בדיוק) התחלתי לעבוד במקום חדש, ועכשיו, בעודי יושב חסר מעש בשדה התעופה, זה זמן טוב לבחון את החודשיים האלה  ולנסות להבין מה למדתי. למה שמתי לב ומה אני צריך לעשות. 
כיוון שזו הפעם הראשונה בה אני מצטרף למקום חדש כשאני חושב שאני יודע דבר או שניים על העבודה, ניסיתי להיות מודע לתהליך הכניסה שלי ולשים לב למטרות שאני מציב לעצמי: אלה לטווח הארוך וגם המידיות יותר. הדבר החשוב ביותר ששמתי לב אליו עד כה הוא שהפער בין המקום בו אנחנו נמצאים כרגע לבין המקום בו אנחנו צריכים להיות הוא עצום. אם לפרוט את זה לפרוטות: יש לנו פערי יכולת בבדיקות המערכת, חסר משמעותי בבדיקות היחידה, קצרים בתקשורת בין צוותים, מחסור בתהליכים תומכים ושינוי תרבותי שאנחנו צריכים לעבור. אבל חוץ מזה, מרקיז, הכל בסדר. 

מעבר לכל הפערים האלה, יש לי גם פערי ידע אישיים: אחרי שעבדתי על מוצר מבוסס WEB עד היום, המוצר הנוכחי דורש ממני היכרות טובה יותר עם מערכת ההפעלה (כרגע אני מתמקד בחלונות, בהמשך אתפנה גם למערכות הפעלה נוספות), וההנחה המאוד נוחה של מערכת SaaS - אני שולט בצורה מלאה בסביבה בה התוכנה שלי רצה, היא כבר לא הנחה שאני יכול להניח. בקיצור, סט שלם של כלים שאני צריך להתחיל להכיר וסט חדש לא פחות של משתנים שאני צריך להתחיל להתייחס לקיומם. בנוסף, העולם העסקי של סטארט-אפ זר לי, ולהחלטות עסקיות יש מחיר אחר שאני עדיין לא יודע עליו דבר וחצי דבר. אני גם לא מכיר את הלקוחות ואת מה שחשוב להם כדי שאדע איפה למקד את המאמצים שלי. אני לא מכיר את צוותי הפיתוח איתם אני עובד ואני צריך לצבור קרדיט בעבודה מולם כדי להשפיע כמו שאני רוצה. חוץ מזה, אנחנו כותבים קוד בפיית'ון, שזו שפה שאין לי ניסיון איתה ואני לא מכיר את הכלים התומכים בה שמאפשרים עבודה אפקטיבית באמת. 
עד כאן, הקשיים ההתחלתיים. 
עכשיו, איפה אני רוצה להיות בעוד נצח וחצי? מה המטרה אליה אני מכוון בטווח הארוך? 
בניגוד למקום הקודם, בו היה נראה לי נכון למחוק את צוות הבדיקות לחלוטין ולהטמיע אותו בתוך צוות הפיתוח (ולמיטב ידיעתי, עדיין עובדים על זה שם), קיומם של כמה צוותים שעובדים על חלקים שונים של המערכת גורם לי לחשוב שהמצב הנכון בטווח הארוך הוא של צוותי פיתוח שאחראים לבדוק את הרכיב שלהם, ונוסף להם צוות שאחראי לשלמות כל המערכת שיעזור לאתר כשלי אינטגרציה ולטפל בתרחישים המורכבים יותר. אני לא לגמרי בטוח איך צריך להיראות הצוות הזה, מה הכישורים שצריכים להיות בו או מה תחומי האחריות המדוייקים, אבל בינתיים יש לא מעט צעדי הכנה אחרים שצריך לעשות. 
אבל, המצב כרגע הוא שיש צוות בדיקות אחד שמספק שירות לכמה צוותי פיתוח, ולמעשה, מזניח לא מעט מהם כי יש גבול למה שיכולים לעשות שלושה אנשים. אם אני מנסה לצייר מפת דרכים גסה, סדר הפעולות שלנו צריך להיות בערך כזה: 
  1. בניית רשתות בטיחות וכלים שיאפשרו לצוותים לקבל מידה מסויימת של ביטחון במוצר שהם בונים. 
  2. תוך כדי 1, צבירת מוניטין ושיפור התקשורת. 
  3. בניית תהליכים שיעזרו לצוות הבדיקות לתקשר עם צוותי הפיתוח ולעזור להם בזמן אמת עם הפיצ'רים בניגוד למצב הנוכחי בו אנחנו מספיקים להגיע לפיצ'ר כשהוא בשלבי סיום. זה כנראה יצריך שימוש בחלק מהמוניטין שצברנו קודם. 
  4. יצירת קהילת בדיקות, או לחילופין, סיפוח של כל הבודקים לצוות אחד לטובת יישור קו בכל מה שקשור לכישורי הבודקים ולאסטרטגיית הבדיקות, כמו גם יצירת ערוץ תקשורת נוסף בין הצוותים. 
  5. אחרי שדברים מתחילים להתייצב - פירוק הצוות המרכזי והטמעת אנשי הבדיקות בתוך צוותי הפיתוח, כשהמטרה היא גם לשדר מידע החוצה, אבל בעיקר להכניס את תהליכי הבדיקות לתוך הצוותים על ידי חניכה פנימית של המפתחים וסיוע בהעברת האחריות על תחזוקת בדיקות המערכת מצוות חיצוני לצוותי הפיתוח. 
  6. כנראה שיחד עם 5, הגדרה מחדש של צוות הבדיקות תחת כותרת אחרת. לפחות בתחילת הדרך, הצוות הזה יהיה אחראי על המשך תיאום בין הצוותים השונים וסיוע לבודקים השונים לא ללכת לאיבוד בתוך הצוותים החדשים שלהם. מהמרחק הנוכחי, הרעיון של Engineering productivity נשמע לנו מסקרן, כמו גם גלישה לצד של ניטור המערכת וייבוא מסקנות פנימה, אולי תחת מחלקת operations. אני חושב שיש לנו שנה-שנתיים (או יותר) לפני שנצטרך להתעסק בזה. 
כרגע, בעודי לומד להכיר את האנשים ואת הסביבה, המיקוד שלי נמצא בסעיף 1, שהוא גם החלק הכי קל - לבנות כלים. בעיות טכניות הן כמעט תמיד קלות יותר מאשר השפעה על אנשים או על תרבות ארגונית. בינתיים, אני מטפל בבעיה פשוטה יחסית - אנחנו צריכים לכתוב מחדש את כל  בדיקות המערכת שלנו בלי לזרוק הכל לפח ולהתחיל מחדש, כי אחרי פעם או פעמיים בהן מישהו ראה מה יש ואמר "אי אפשר לעבוד עם זה, אני אכתוב לכם משהו חדש וטוב", אין לנו את הקרדיט הנדרש כדי לומר בדיוק את זה. אז אנחנו לוקחים את הפרוייקט הקיים ומעבירים אותו מתיחת פנים יסודית. זה נותן לי הזדמנות להיות יעיל עם מעט מאוד ידע ולהתחיל להרחיב את ההשפעה שלי משם.

אני צריך לשים לב שאני לא נשאב יותר מדי לתוך המשימה הטכנית הקלה ולהקדיש קצת זמן בבניית גשרים לצוותים האחרים. גיליתי שקשה לי מאוד לעשות את זה כשאני אפילו לא יודע על מה עובד כל צוות בכל רגע נתון. אחד היתרונות של סקראם היא הפגישה היומית, או ה"daily standup", שמאפשרת יחסית בקלות להתחבר לאנשים בלי ליפול עליהם באמצע היום ולשאול "מה אתה עושה? אפשר להפריע? אפשר לעזור?" אנשים אחרים עובדים כרגע על הכנסת תהליכים כאלה או אחרים, אז אני מקווה לנצל אותם כדי לשפר את המאמצים שלי במישור הזה, אבל גם אם לא, אני צריך למצוא דרכים אחרות למשוך אלי מידע ולהכיר קצת יותר את האנשים.

זהו, פחות או יותר.

אה, דבר אחרון שלא לגמרי קשור לפוסט הזה, אבל אני רוצה לנצל את ההזדמנות הזו ולהזהיר את כל הקוראים - פיית'ון היא שפה שמתאימה לכתיבת סקריפטים קצרים ופרוייקטים שנזרקים לפח אחרי שימוש קצר. ברגע בו עוברים את הגודל הזה, צריך להתחיל להילחם בשפה כדי לעשות דברים שאמורים להיות טריוויאליים ויותר מדי דברים מבוססים על קונבנציות מכדי שיהיה אפשר לסמוך עליהם. אם אתם מתלבטים עם מה לעבוד ואין לכם סיבות ממש טובות - הימנעו מפיית'ון. אפשר לפרט, אבל זה לא המקום, אז הנה כמה מאמרים שכבר עשו את העבודה במקומי.

Starting in a new place


I blinked, and two months(to the day) have passed since I joined my new workplace. and now, siting at the airport with not much to do, is a great time to reflect on those two months and try to figure out what I have learned, what I've noticed and what I should be doing.
Since this is the first time that I join a new workplace  with some confidence about knowing my way around and holding some firm beliefs about the way things should be, I tried to be conscious about my ramp-up and notice the goals I set for myself - the long and short term ones. The most important thing I've noticed is that there is a big gap between where we currently are and where we should be. Or, to be more specific - We have a large debt around testing in the system and unit levels, communication channels that need to become more robust, lack of supporting processes and a cultural shift that we need to undergo. Mais à part ça, tout va très bien. Besides,
Besides all of these gaps, I have my own personal gaps to fill in: Having worked on a web based product until now, I never needed to dive into the workings of the OS (right now I focus on catching up on Windows, other operating systems shall follow) and the really convenient assumption of a SaaS solution - I can control the environment in which my product is running - is no longer true, which means that I need to think different variables than those I'm used to. In addition, the business world of a start up is foreign to me and business decisions have an impact I don't fully understand yet, I am not yet familiar with out clients or what is important for them to help me focus my efforts, and I still don't know the development teams I work with enough, certainly not enough to have the stack of credit I'm used to rely on to influence things. Oh, and we write code in Python, a language I don't have a lot of experience in and I'm not familiar with the tools and libraries that enable working with it effectively.
So, those are the starting challenges.
Now there's also the question of where I want to get to,  you know, once I had all the time in the world to set things the way I believe they should be. Unlike the previous place, where I believe it was right to completely remove the tester role and just stay with engineering teams (They are still working on it, to the best of my knowledge. I think that me leaving was a good step in that direction), I believe that in this place, since there are many teams working on different parts of the system, it is still the right thing to have a team that will be responsible for the larger picture. I'm unsure about how to brand this team or what exactly should fall under its responsibilities, but there's enough to do until then. One thing I am sure about is that this team should rely on strong testing capabilities that should exist within each team, so we still have a lot to do until we need to figure this out.
At the moment, though, the current situation is that there is a dedicated testing team that should provide service to three other developer teams (some of which have a dedicated tester, but from what I've gathered, they are being swallowed into doing feature development and are not able to contribute enough to educating the team or even just taking care of the testing gap), so  if I try to sketch a way forward, I imagine a growth and a shrink.

  1. Build safety nets and tools that will enable teams some level of confidence in the product they are building. 
  2. While doing 1, increase our reputation stack to better influence what is happening. 
  3. Set in place the processes required to connect with feature work while it is being defined and executed instead of getting something vague at the end. This will require using some of the reputation tokens we've accumulated. 
  4. Create a testing community, or, failing that, a testing team comprised of all people in testing positions - the idea behind this is to boost and align the testing skills of everyone, as well as a unified testing strategy and also to create another communication channel. 
  5. Once things are working, roughly, split the team and distribute most of the working force to be embedded in the development teams. With the goal of having them educating the rest of their new team, helping them take responsibility of testing and pushing out relevant information.  
  6. Probably at the same time as 5, redefine the smaller team left after most team members have been embedded in the teams. Initially, it will have the responsibility of maintaining the testing community and keeping the communication channels open, as well as help the testers not to get lost in their new teams,  but after this is covered, I'm unsure. For the time being, the concept of having an "Engineering productivity" team sounds quite appealing, but we won't know until we get closer if this is the correct usage of that team. Maybe, since keeping tabs on the bigger picture is part of that team's role, it will be a good idea to have that team as part of the operations group and push towards having a real DevOps culture. I believe we have at least a year or two before we'll have to deal with those specifics.
At the moment, while I'm still learning my environment, my focus is on the first bullet, which also happens to be the easiest one - build tools. Technical problems tend to be almost always easier than influencing people or culture. In the meanwhile, I'm dealing with a simple problem - we have to re-write the existing testing framework without actually saying we're doing that - after at least one time when someone said "We can't work with that, here, let me show you how to do that" we don't have the credit to do the same, so instead we refactor. Heavily. It gives me a chance to be effective quickly, even if only in limited capacity, and start building up from there. 
I need to notice that I'm not being carried away too much into the easy technical task and invest some time in building bridges to the other teams. I have also noticed how much I relied on the scrum daily standups - I feel a lot more comfortable hearing "I'm doing X" and then asking that person a bunch of questions, or suggest my help than I am comfortable interrupting someone and asking "Hey, what are you doing now? Oh, I have zero relevant input? Thanks for your time". People other than me are working on instituting such procedures, so I think I'll wait a bit and try to leverage those efforts. 

That's it, I think. 

Oh, one last thing, not completely related to this post, but I would like to use this opportunity and warn all readers: Python is a scripting language. It is not suitable for anything long-term or bigger than a couple of files. Once you are over that size, you have to fight the language to write maintainable code or do things that should be trivial, and there are too many convention-based practices out there to actually be able to rely on them. If you ever find yourself in a position where you can choose and you don't have some compelling reasons to do otherwise - avoid Python. I can go into details, but this is not the place, so here are some articles that do this for me.

Saturday, June 1, 2019

Nordic Testing Days - day 2



The second day of NTD had started just great with Alex's keynote about exploratory testing, microheuristics, and the general recommendation "notice what is it that you do" as a way to both improve (your own techniques as well as teaching others)  and help others notice the expertise you've gained. You are doing everything besides "just clicking around". This keynote had everything a keynote talk should, dinosaures included.

After the keynote I missed (again) Bailey Hanna's workshop on feedback and communication in the workplace, and instead, evacuated myself to ER.
To cut a long story short - I fell from my bike a bit over a week ago, and until then I thought recovery was going fine, so I didn't bother checking it up. After all, it was only a bruise, and it is normal to have a bulge where a hit has landed. However, once the coloration was mostly gone and the swelling did not, I did the obvious thing and googled my symptoms the night before. The results - scary. I woke up that morning at 5:30 AM and couldn't go back to sleep, so I did the responsible thing and called a doctor from my travel insurance. I described the fall and the symptoms, and strictly avoided sounding my guesses or fears to the doctor (which, in case you wondered, is the correct thing to do if you did google your symptoms - don't interfere the professionals with your uneducated guesses). I wasn't very happy to hear that the doctor was worried about the same thing as I was, and he recommended getting it checked quickly. So I did exactly that. I asked the organisers for the correct place and took a cab there.
The Estonian medical system seemed to me as efficient as I could hope for - I was taken within 10 minutes to have my vitals checked and soon after saw a doctor. Upon seeing my injury, The doctor made one of the sounds you don't want your doctor to be doing, and sent me to do an ultrasound. Then I waited, and as I did, I checked my options of returning home sooner, hoping that the doctor will say it's safe enough to postpone a surgery until I'm home. Just one thing - finding out that you might be in a life-threatening situation is no fun, and doing that far away from your home & family is even less so, please avoid that if you can.
A couple of hours later, the ultrasound results were in, and at least as far as it seems from the scan, the real situation is not dangerous at all (though it might get complicated a bit). The treatment: rest, and take an off-the-shelf medication for the pain.
Cool, that left me feeling a lot better (it's amazing what fear can do to your general feeling), suffering only the effects of not enough sleep and no real food since morning, where for the same reasons (lack of sleep, fear) I didn't have that much of an appetite. Anyways, I got back to the conference just in time to catch the closing key note, where Erik Kaju told us about the engineering practices in transferwire. It was nice, even if  I've heard such talks before. It is always nice to see that some companies are doing things a bit better than what we do back at home and we can improve.

After the conference I went to sleep for an hour, and then I joined Lisi and we went to eat dinner with Joep and Elizabeth. We tried some sort of an Indian restaurant, which was quite nice. Not as nice as the company, but still :) We broke off around 22:30 and walked back to the hotel (except for Elizabeth that was staying elsewhere). Somehow, we ended up talking at the lobby until almost 2AM, but then it was (well past) time to go to sleep.

Quite a good day after all.

Friday, May 31, 2019

Nordic Testing Days - day 1


Tutorial day is over, and it's time for the first day of the conference. I did the responsible thing and got enough sleep, despite some people (whom name shall remain undisclosed) who were dragging speakers to try out this "traditional" alcoholic beverage (and by "traditional", I mean "is probably going to kill you horribly"), so a fresh start for a new day.
I got into the venue just in time for the keynote about machine learning and testing. It was interesting,  and would have made a good track talk, I was expecting more out of a keynote.
Then, I went to give a workshop and teach people about unit testing. It's a bit long, and setup always takes longer than planned, but all in all,  I think it went well, I hope the participants agree.
After lunch i went to participate in Alex Schladebeck's workshop on testopsies and micro-heuristics, in which we spent some time learning about how to think about what it is that we do while testing. Narrating a testing session can be quite challenging, but very insightful. Being forced to communicate reason ("I'm surprised by x, so I'm going to investigate that by doing y") is a great way to both learn what we do and teach others how we think.
Apparently, one opening keynote and two workshops leave time only for the closing keynote of the day, in which Raimond Sinivee told about his journey and how relying on his existing testing skills he was able to become a well rounded software engineer (for the purpose of this talk, an engineer is someone who has both testing and development skills and is functioning in those two roles). It was a very good keynote, inspiring people in what I think to be a good direction.
Naturally, things do not simply end after the last lecture - we had a conference party, alongside with two activities I really like: lightning talks and Powerpoint karaoke. I could probably tell you about it, but it will not do it any justice. I guess you really should have been there.