DEV Community: Tanja Lichtensteiger

Don't Drown in Documentation

Tanja Lichtensteiger — Sun, 04 Jun 2017 11:08:03 +0000

In software development, how much documentation do you need?

My answer: Just enough.

I do not hate documentation, I am actually pretty good at organising and churning them out. But then I began to feel it was an exercise in futility. We could not keep up with the pace of change and it became quite cumbersome to maintain.

Now there are many who may disagree with my stance, but hear me out. I am not advocating the eradication of documentation, but asking you to really question how much documentation you or your team needs that isn't already being created as part of other steps in the natural process of developing software.

Code

If you and your team write code well, I argue that in itself is great documentation. If code is kept to a consistent standard, organised and is easily readable, you have in your hands excellent documentation that is always up to date. Even consider not having comments in your code, which, when not well maintained, is usually already wrong. The running code never goes out of date.

Tickets

As part of your development, you might be creating tickets for features or workpackages. These could be stored in systems such as Redmine or Atlassian's JIRA. They also act as great historical documentation and within them usually are the reasons why certain decisions were made at crossroads during builds. Even tickets capturing bug fixes hold conversations that may have resulted in the build or rebuild of features. If a ticket is used to detail what is needed to be done, any relevant diagrams and visual aids should be attached to them as well. Keep up with consistently capturing your requirements in tickets, you need not create them elsewhere.

Test Scripts

Test scripts are an incredible form of documentation. If they cover all paths and all aspects to test your build, they accurately explain how your software works. If you follow Test Driven Development (TDD), these scripts are also always up to date.

FAQ & other Must-Do Documentation

Questions that keep coming up again and again, requiring the same answers that rarely change, highlight the need for documentation. This is what needs to be compiled in a quickly accessible resource like an FAQ. It could be stored in shared spaces such as Redmine Wiki or Atlassian's Confluence. Again, I would advocate that such documentation only cover what is asked for frequently.

Training

After all of the above, I am aware that this may cause a learning curve. Teams will need to be trained to understand this new way of working. That they aren't looking for word documents stored in a shared drive anymore, but need to creatively explore other sources, to find the information they need. It may mean initial work in the beginning, but if it saves you time from creating documentation that no one ever reads, it will give you more time to deliver quality software to a deadline. Training, as an investment, is never a bad thing.

Thank you for reading. Please feel free to share your thoughts and advice as I am also keen to learn and improve my way of working.

I have specifically left out documentation that is customer facing, as that should ideally not be written by developers, but by someone who fully understands the customer's business and can communicate in their preferred terminologies.

The search for IT’s Holy Grail: Fostering DevOps Collaboration

Tanja Lichtensteiger — Mon, 29 May 2017 21:00:00 +0000

This article was originally posted on Dell EMC Tech Page One.

The Tech industry is constantly drawn to new concepts and one of the most talked about topics of the moment is DevOps. This new kid on the block promises to deliver a faster response to business change while reducing single points of failure. But to successfully implement a DevOps culture in any organisation collaboration is key. Yet many teams struggle to obtain this highly sought after prize due to fear and distrust between Software Development and IT Operations.

So how can this culture of collaboration be fostered? Based on experience of working on DevOps projects over the last few years, here are my tips for making sure you get off on the right foot.

Not another Restructure!

The first misunderstanding many make when they wade into DevOps is thinking that a restructure of their organisation is required and that a new DevOps team needs to be created. But DevOps is not a branch in your company’s organisational chart, but rather a culture and a way of working together that bridges the gap between Software Development and IT Operations. It can also include members of other teams, such as Security and Networking. It is born out of the Agile philosophy, valuing people over process over tools. Teams work together through an entire service lifecycle, all the way from design to implementation to support to the eventual decommission. The lines that split the tasks between teams start to blur, but this a good thing!

Why is this a Good Thing?

Poor collaboration affects the outcomes of development projects. Fostering a good DevOps culture enables:

Faster software development
Frequent software delivery
Improved service quality
Reduction of bottlenecks
Creation of a holistic environment
Improved working relationships

Get off my Land!

One of the obstacles to collaboration is the distrust between developers and IT Operation teams. Trust needs to be built for all parties to willingly move their territory lines. Before you can build this trust, you need to empathise and understand what each party fears.

So what do they fear? No matter how much IT Operations reassure them, developers fear that the environment they are building in will be nothing like the production environment. If this is the case, any testing prior to implementation is meaningless. IT Operations on the other hand fear that if they allow developers to help create and configure these environments, Ops will be cleaning up the mess left in their wake. In the most negative mindsets, the other is out to get their job.

During initial discussions all teams need to openly acknowledge these fears. Write it on post-it notes before sticking them on a white board. Facilitate that discussion so that team members all understand where everyone is coming from and address it with logic and solutions. Rely on allies to help you.

Find your Allies.

There are individuals on both sides who will want to collaborate and believe in a closer working relationship. Join them for coffee and talk about the best way to implement a collaborative culture. Ensure that you all share the same message and one voice, regardless who is asked and who asks. As they bring up DevOps in conversations, support them and they will support you back. The more others hear it repeated by different sources, the belief in this new culture will gain strength and eventually momentum.

The Big Sell.

Besides listing the benefits to the organisation, you need to sell the benefits to the individuals. This includes access to new skills and training followed by the opportunity to put it into practice. At the same time reassure them that they are not expected to be an expert of all these new skills. It is more about breadth than depth. Show them that you value their own niche and expertise.

Tool Up

After people and process, comes tools, which will help support this new way of working. Tools that allow automation, continuous integration, delivery and deployment, should be agreed by members of both teams and implemented together. These tools should allow process transparency and open discussion.

Job done?

You finally reach the DevOps nirvana! But it isn’t the end of the line. Like any ecosystem, this culture needs to be maintained to remain healthy. Existing relationships will need to flourish and the belief in the culture will need to spread to new employees entering the organisation. You and your allies will continue to be the gatekeepers, guarding this trusted collaborative partnership.

I'm a Techie on TV! Save Me!

Tanja Lichtensteiger — Thu, 25 May 2017 16:59:49 +0000

The overused stereotype of a techie is someone quite introverted, who would rather not present to audiences and actively shuns the limelight. The idea of getting on TV or radio would be equal to having their skin slowly peeled off with a blunt spoon.

But when you do feel brave enough to engage with the media, there are benefits. If you have a message that you would like to get across to the world, this is the box that you can stand on to be seen.

Here are some tips to help you on your way when you do get contacted by the media:

Be Flexible
Journalists are busy and live in a world that is in constant change, running after one breaking news item after another. They are more likely to work with you, if you are able to understand the challenges they face in their jobs and accommodate their time slots. The quicker you reply to their messages and keeping your schedule flexible, makes you a prime candidate for their go-to-person on certain subjects.
Politeness Costs Nothing
As much as some would like to believe otherwise, people who work in the media are human and like everyone, appreciate the small things. Always greet them and end your interview with a thank you. Your manners will come across well not just to the journalist, but to the audience watching.
Be Helpful
Before the interview, provide the following information as soon as possible to help them prepare their work.
- Your Name
- Your Job Title
- Your Company or the one you work for
- Videos / Photos if visual aids will help explain what you are trying to get across
- Facts about the topic and any other material that you may feel will be of interest. They may not use it, but you have helped them further their research into the topic that is usually out of their comfort zone.
Keep Jargon to a Minimum
This is obvious and you do hear about it all the time while working in Tech. You need to be able to speak to people who are not well versed in technical jargon. You work in a niche, but if your message needs to go out to a wider audience, you need to be able to speak their language.
Keep it Interesting!
Abstract the information appropriately to your target audience. What are they looking for? The interest is not necessarily in all the specific details, which may go above the heads of most listening. Be aware of this and they will less likely tune you out.
Build a Rapport
Working with the media may be a rare occurrence for you, but for the journalist, this is their job. If you find a way to help them enjoy their work, even better! They will look forward to working with you again.
Avoid the Dead Air
Nothing is worse for journalists than having you respond to their questions with awkward silence while you are live on air. Avoid this at all cost. Prepare your answers beforehand, ready to respond to questions you believe they may ask. It is worth asking before the camera starts rolling, what their first question will be to help get you started. If you are caught in the dreaded dear air, they will also try to help you out of this hole, so latch on to this helping hand and don't let go.
F*** Fake News
Check your facts. Avoid spreading incorrect information, just because it sounds juicy. It will spread like wildfire and you will be criticised by those in the know. This will only damage your reputation and the message you are trying to get across.
Do Not Lie
This really should go unsaid, but like the last point, people are curious creatures. You will be found out.
Have Fun
Not many people get a chance to talk about their passions in front of the media. Stay humble. Be grateful. Enjoy the moment!

Hack Yourself

Tanja Lichtensteiger — Sun, 23 Apr 2017 12:33:53 +0000

April 22, 2017 is my bionic birthday. At around 17:15 I chose to upgrade myself. An NFC tag was implanted into the webbing of my hand. This was the day I had waited for since I was a teenager, watching the original Ghost in the Shell and daydreaming of integrating with the machine world.

If you thought it was not yet possible for an individual to choose to technologically modify themselves, let me assure you that the dawn of "transcending" has begun to split our evolutionary horizon.

People may question the ethics of such procedures, but I believe in the importance of distributed knowledge. This technology is out there and in the hands of people and organisations that I do not fully trust. Instead of fearing it, I choose to understand and learn how to hack it. Hopefully I am one of many with knowledge and skills to be the defense against any unethical practice. Humans are both the cause and the cure of technology gone wrong.

With that in mind, myself and five other individuals were invited by the Leeds International Festival to receive implants as part of their Biohacking, Cyberpunk & Hacker Culture event. With TEDx Speaker and Body Hacker Hannes SjÃ¶blad observing the procedure, we were upgraded.

The tag was produced by Dangerous Things and implanted into my hand by a lovely body piercing professional (who decided to become one of us). The procedure with the sterile injector felt like a deep bite for a couple of seconds and then it was done. I could feel a tiny foreign object embedded into the flesh of my hand.

Within minutes I started to hack myself.

One of the first steps I took was to secure my NFC tag from malicious attack with the Dangerous NFC App. With 17 years experience as an IT professional I take technology security very seriously.

Using a tag writer I found it very easy to manipulate the data with my mobile phone. I can imagine if it came in contact with those of deviant inclinations, it could have been easily sealed in a way that I would not be able to handle the data stored within.

It has been less than 24 hours since I upgraded, but I have already been able to use my new component to:

bring up my twitter account
play one of my favourite songs
call me an Uber to take me home

I plan to enjoy this journey with my new feature and look forward to writing about my future enhancements. But I will always remember the first bit of data I stored into my body using my latest upgrade. Words that spoke to me when I was a little girl. Words that guided me as I explored the revolutionary cyber landscape that was being built.

Cogito ergo sum.

I think, therefore I am.

Words that I will literally carry with me always.

Why Pay It Forward

Tanja Lichtensteiger — Sun, 16 Apr 2017 14:06:49 +0000

Over the past two years I have been involved in outreach/mentoring programs and events which focused on getting more people interested in careers in technology. As a passionate techie, I want everyone to be encouraged to join in, specifically women and ethnic minorities, as I am a representative of both and there are still far too few of us in this field.

Friends have asked me why am I spending most of my free time constantly speaking, writing, networking and for what? To potentially help people enter my industry, who may prove to be better techies than me and eventually compete with me for jobs. (Honestly: what a terrible way to look at it!)

I often reply: “Don’t you remember the person who helped you?”

Because I do.

There are no words to express the extent of my appreciation of the people who believed in me, took risks and went out of their way to give me a helping hand.

One of those was Herr Markus Erkenbrecher, an IT big shot (at least to me!) in Migros, the largest retailer in Switzerland.

I sent a CV off to the company not knowing if there was even a job available. That CV was one of over 80, which I sent out to different companies in the span of two weeks.

Honestly, I was 17 and desperate. I had strong logical thinking and problem solving skills, but my German was not perfect and my French was appalling. Unfortunately they were all required skills if you wanted to get ahead in any technical vocation in Switzerland. University closed its doors on me, I saw no way forward to move into tech and my career counselor was suggesting I go into hairdressing instead!

Thankfully my CV landed on Markus’ desk. He somehow saw through my poorly written German, his curiousity piqued by my potential. I remember getting a letter detailing their IT apprenticeship program and inviting me to take some tests. It was like finding the golden ticket.

I remember sitting in the waiting room (the only girl) with other applicants, brimming with excitement. I am not usually excited about tests, but what I had was a chance to prove myself. I was unphased.

And I did.

Months later Markus told me that although my language tests were subpar, the result of my logic tests stood leagues above the rest. This was still enough for me to miss out on this apprenticeship.

The next round of the application process was to work in the company for one week. Along with the other applicants who made it through, I learned about the company, its systems and its values. As I did so, the company was learning about us, judging our suitability.

During that week employees met me with thinly veiled bemusement. I could see it in their eyes that they did not believe I would get the job. After all, how can a brown girl, who spoke broken German, fit within a giant of a company, a gatekeeper of Swiss history and tradition. The employees knew it and the other applicants knew it too. The latter did not hide their opinions on that matter.

At the end of the week, I was invited to a formal interview. And in that interview you can bet I tried my damnedest to convey to the panel how much I wanted this job, how hard I would be willing to work (take language classes at night school, no problem!) and how I would not let them down, if they just gave me a chance.

After my impassioned speech, I remember Markus leaning forward and saying: “You are a risk. But I am going to gamble on you.”

And he did.

The risk was not imagined. All through the three year apprenticeship his reputation was influenced by that decision and my resulting performance. People questioned why he had hired me and why he had given one of the two valuable spots of the company’s IT apprenticeship program to a brown girl, who should be learning to cut hair.

14 years ago I passed my IT Apprenticeship with flying colours. The doubters became believers. And the doors to my future career swung open.

I have not (yet) needed to use French in my current career as a Software Development Team Leader, but I constantly apply what I have learned from the pages of Markus’ book.

Take a risk, pay it forward and change lives.

Hi, I'm Tanja Lichtensteiger

Tanja Lichtensteiger — Sat, 18 Mar 2017 07:30:00 +0000

I have been coding since I was 8 years old and professionally for 17 years.

You can find me on Twitter as @grappleshark
You can find me on Github as @grappleshark
Website: https://grappleshark.github.io/

I work for Leeds Beckett University as a Software Development Team Leader. No, I don't have a degree - I have grit.

I live in Leeds, Yorkshire, UK. I used to live in Switzerland, Philippines, Malaysia and Indonesia.

I mostly program in PHP, Web, Oracle toolsets, Java, C# .NET.

I am currently learning more about Python.

In my free time I am currently building an Athlete Communication Platform for Yorkshire County Cricket Club.

Feel free to talk to me about Software Development, DevOps, Diversity in Tech, Data and any emerging technologies/cool stuff.

I am partial to pistachio ice cream.

Nice to meet you.