DEV Community: Aga Zaboklicka

Nevertheless, Aga Coded

Aga Zaboklicka — Thu, 08 Mar 2018 07:08:35 +0000

I wanted to quit writing software for good.

Nevertheless, I coded. And I still do.

I've been a software developer for 3 years then. And I totally didn't feel like getting up and going to work. I struggled with my tasks and worked much slower than I used to. I tried to look for another job but it didn't go well. I feared that I would never get another programming job. And I didn’t want to look at the code ever again. I felt mentally and physically exhausted. Maybe even depressed.

But I've got a great job. I worked remotely and had time to travel. I had a supporting boss and great coworkers. But I still felt like something's amiss.

Then one night I woke up with this crazy idea: I'll take a break from my life and go to Japan.
I was so excited I couldn't sleep. I set up with my boss organized everything within a week and two months later I was on the plane heading for Japan. 3-months-long unpaid vacation.

It was great. The first month was full of sightseeing in Kansai and volunteering in the guest house. After first few weeks though when I already got used to living in Kyoto I started to think my life over. Where do I want to be by the end of next year (it was December, you know)? What do I want to do? I started to ask myself those questions and figured out all the stuff but work goals.
The whole vacation went by quickly, as it usually does. I came back still not knowing how to change my profession.

I never did. I didn't even change my job. I didn't need to anymore.

When I got back I restored my faith in programming. I ended up with an amazing project. I had some time to ramp up and gradually ease my way back into programming. I've got new, more interesting and challenging tasks. James, my project manager at the time, was one of those rare species that knows how to say no so I was never overloaded with work. If I ever had to pull long hours I could compensate for it with a breather later on. It all went to place.

I knew where my life was heading and I noticed that being a software developer is fun.

But there's one more thing that really, really helped me.

Conferences.

I went for my first software development conference way too late. It was just a few months after I came back from Japan. It gave me quite a kick and made me wonder why was I there so late? I've met a whole bunch of like-minded developers. Developers sharing their stories about overcoming work, code and life-related troubles.

I'm more mindful of how I work since that year. I had time to notice, that having time and space to do something fun that's not writing code helps a lot. It helps me to stay motivated and productive in the long run.

Also posted on https://jumpstart.blog

I began to code because...

While studying electronics I got hooked on designing software more than hardware.

I recently overcame...

The barrier to getting a first full-fledged programming job in a new country (Canada)

I'm excited about...

Clean code and having my code properly reviewed last few days...

My advice for allies to support women and non-binary folks who code is...

Find a mentor, a job you like and a team that supports you.
Pick up your battles and voice your concerns when you feel something's not right.
Ask for what you need
And, most importantly, whatever happens, keep going.

How to write a SOLID dev resume to be 2018 STAR

Aga Zaboklicka — Mon, 22 Jan 2018 06:23:58 +0000

The post comes from my blog, where you can find my resume (more or less) in *.pdf if you're interested.

I've been coaching IT people with their job search and resume writing since the end of November. And I've noticed that a lot of us struggle (and yes, I do too) with writing this scary piece of paper. So here is the compilation of the knowledge and most common tips I gave so far.

KISS - Keep it short and simple

A resume is your marketing piece to encourage recruiter or hiring manager to interview you (and not an elaborate essay on your experience/projects). Your resume shows your most important and relevant skills for the position you apply for. I'm not telling you to do a one-pager (this info is long outdated), but 2 pages are enough space to give the other person of who you are and what you know.

Make it SOLID (as in SOLID by Uncle Bob)

Single Responsibility Principle

One resume for one position/one job posting. Your resume will be different for IT Architect Role than for Senior Software Engineer position. And it'll be different for Senior Software Engineer in ABC Company and for XYZ Corp.

Open/Close

Close it for modification by opening it up for extension: you'd want to extend your resume by adding extra info in cover letter by there (yeah I know it's not 100% like this in open/close but I think you can relate ;))

Liskov substitution

“Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”
Meaning: if you were able to do something as a junior it's you're still capable of doing it with more experience.
DRY comes in handy here. So please don't repeat yourself.

There's one exception here, though. If what you did in each job is a basic need for the position you're applying it's good to showcase throughout your career. E.g.: applying for JavaScript Dev describe all JavaScript development roles/tasks. Tweak it so they don't seem the same, e.g:

Software Developer, ABC company

Developed, maintained, debugged and fixed bugs in distributed Java and JEE applications

Software Developer, XYZ Corp.

Involved in full-stack software development based on Java, Struts, JavaScript, Hibernate and DB2

Interface segregation principle

Many role-specific resumes are better than one generic resume. (There's nothing more to add to it)

Dependency inversion principle

"High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions."

Your abstraction is the job you apply for so everything you write should be based on that job/job posting. Keep only the details you're asked for in the job description. Again KISS works nicely here too :)

Start with master resume

A master resume is like a database of everything you did thus far. It's a great reference point for your future resumes and lists all or the most important skills and accomplishments.

Accomplishments instead of tasks

Few accomplishments are better than just to list your duties. E.g:
Task: Wrote JUnit tests
Accomplishment: Assured expected behavior of applications by writing JUnit tests and ensured 85% code coverage

You can find a lot of generic articles on how to turn your task into accomplishments, like this one on The Muse.

If you are still not sure on how to approach it here's a little advice:

Be a STAR of your resume

Think about a Situation when you performed that Task.
What Action did you take and what was the Result?

Then write it in POR format:
Past tense action verb
Object of your statement
Result of your action

And try to add some keywords in between.

E.g: Guided a team of 4 developers using Kanban to design, configure, and test RESTful loyalty cards management system run on RedHat Linux

I welcome all questions, so don't hesitate to ask :)

Are you (programming) in your comfort zone? Please don’t.

Aga Zaboklicka — Sun, 12 Nov 2017 00:43:00 +0000

Originally posted at Jump Start Blog

I worked as a software developer using only Java tech stack for over five years. And I'm pretty comfortable with any Java code. I started playing out with JavaScript, namely node.js, just recently. JS is similar in many ways to Java but it's different. As Java dev, I've seen JS as quite a dirty front-end tool. Using node made me appreciate the language and shift my thinking processes. And the more I used it the more fun I had. And now I'm using MEAN stack at work. And it's soooo exciting :D

I wasn't comfortable with using node at first. It made me anxious. I struggled with expressing my thoughts properly in JS. I wasn't sure if the code I wrote follows good practices or any architectural standards. It was outside my comfort zone.

And you also have one. A comfort zone.

The comfort zone

The comfort zone in a place where you feel safe. Comfortable. It's where many people operate.Â

Everyday activities that you’re used to or that don’t make you feel anxious and uneasy are part of your comfort zone. It’s the location of the skills and abilities you’ve acquired. You're pretty productive in your comfort zone.

So why should you step out of your comfort zone?

You're safe. You're productive. You don't feel anxious or stressed out.

But then you're bored. You don't feel challenged. You can’t make progress or build skills in the comfort zone since it consists of the abilities we can already do easily. It's a stagnation.

And as a software developer, if you're not moving forward it means you're already moving backward.

The biggest benefit of stepping out of your comfort zone is your personal growth. When you decide on a task that's outside of your comfort zone and then complete it, your confidence will grow. You'll feel accomplished.

Outside of comfort zone

Just outside the comfort zone is a learning zone. The skills and abilities in the learning zone are barely out of reach. They’re neither so far away that you panic nor close enough to be too easy.

Since a person can only make progress by choosing activities in the learning zone, it’s important to be able to find your learning zone. The learning zone may be wide for some and thin for the others. But as you start to challenge yourself you begin to extend that zone.

How to know you're moving forward

If you don't know where your learning zone is, try testing yourself. If the task at hand is challenging enough to have you engaged (and not bored), but not hard enough to discourage it means you're in the learning zone.

Here are some examples of some task you can try to challenge yourself (bigger and smaller):

learn another IDE (try Visual Studio Code or IntelliJ if you're using Eclipse)
use different OS (for example try Linux when you're used to Windows, or Fedora when you're used to Debian based OS and don't feel like working on Windows)
use command line instead o the user interface
use vim instead of notepad/scratch
learn a different programming language (like JS when you're using Java)
learn a programming language that uses different programming philosophy (for example if you're used to object oriented languages try something functional: Clojure when you're programming in Java, C# & Objective-C)
if you read only technical books try reading some fiction (really)

Don't get yourself into panic zone

Outside of a learning zone is a panic zone. Like the comfort zone, you can’t make progress in the panic zone. Activities in the panic zone are so tough that you don’t know how to approach them. Instead, you become so anxious you can no longer think. Or you're uncomfortable and possibly discouraged.

For example, if you only used object oriented Java over your entire programming life and have no idea how to approach Haskell try learning .net first. Or try using lambdas and learn functional programming in Java.

Stay in the learning zone

As you operate in the learning zone, you will get more comfortable with the current skills and they’ll start to move into the comfort zone. As this happens, tasks that were once a part of the panic zone will move into the learning zone and the cycle will continue.

Good luck in your learning endeavors!

It takes time to make a team...

Aga Zaboklicka — Wed, 18 Oct 2017 20:37:38 +0000

Building a team

I went sailing some time ago. For years I used to sail minimum once a year with a group of my friends. But as we got older and built our own lives it became harder to get a group together.

So this year I decided to join another crew. It wasn’t just me thinking that away so we ended up on a boat without knowing each other. Group of total strangers that never met each other before. The only thing we knew about each other was that we all sail. But our skills, sailing knowledge, habits and expectations were completely different. We didn’t know what to expect, what position to take and what responsibilities. Every task was a struggle. The first day was too long and tedious.

It took few days for us to form somehow organized crew. As we got to know each other we started to appreciate and understand other participants. We started to trust. But at first, it was a total disaster.

It’s similar in whenever the team has to form. Also so it is in software development.

Stages of forming the team

A new team doesn’t perform well when it first comes together. Forming a software team takes time. And there are four noticeable stages of that development process: forming, storming, norming and performing were identified by Bruce Tuckman in 1965. Adjourning, a fifth stage, was added by Tuckman about ten years later.

I'm not going to describe those stages here (this time), but if you're interested you can go on and check the rest of the post on my blog.

If you were hit by a bus tomorrow would your project be dead in the water?

Aga Zaboklicka — Thu, 03 Aug 2017 08:10:25 +0000

Originally posted on my blog

If you were hit by a bus tomorrow...

If you were hit by a bus tomorrow (knock on wood) would your project get stuck?

I still remember when one I worked on did.

Well, I wasn't exactly hit by the bus, but from the project standpoint, it was close enough.

We worked on an important security change and I was the only dev assigned to the module. The job could be done within acceptable time frame by a single developer.

But I got keratitis (eye's cornea inflammation) and had to take three-weeks-long sick leave (with no option to work on the computer).

Yikes! We’reÂ dead in the water

There was no developer to take over my tasks. When I got back the project was late. The new functionality was delivered on time only because we pulled quite serious overtime later on. It almost got me sick again.

if(busFactor == 1)

The bus factor is the number of people on the team who have to be hit by a bus to get the project in serious trouble.

Take a look at your team.

Is there a person you can't complete the work without? Will you be able to function when the most experienced developer leaves or will you miss your commitments?

If the answer is, “Yikes! Without him/her we’d be dead in the water, your bus factor is one. Prepare for a project delay or sprint failure in the near future.

fix(busFactor);

There is no quick fix or simple solution to the low bus factor.Implementing certain practices, though, will help:

Implementing some practices, however, will help:

Work in a shared space and/or daily stand-upsÂ (communication gets better).
Regular code reviews (ideally real-time) and pair programming (you share your knowledge about the module you work on).
Test-driven development (if someoneÂ gets stuck, she/he can check the intent of the code in tests)
Team focused on one project at a time (team focus shifts fromÂ specific specializations (such as “being the SQL guy”) to how to work together to deliver a specific set of changes)

Feeling stuck? Getting past the programming blockade

Aga Zaboklicka — Tue, 01 Aug 2017 09:25:37 +0000

This post was originally published on my blog.

The production system broke last Tuesday...

I got a phone call last TuesdayÂ around 8 pm. The operator told me a daily task broke in the production and I had to take care of it as soon as possible.

I turned on my laptop and connected to the customer's system. I checked the error logs and found a decent error in the file. I found the place where the exception was thrown. Then I analyzed the code in the function.And I had no idea what was the real cause of the system error. No clear bug in the code... I looked at it from every angle and couldn'tÂ find a solution.

I tried to fix it but got stuck...

And I still had no idea what was the real cause of the system error. No obvious bug in the code... I looked at it from every angle and couldn'tÂ find a solution. I got stuck.

I finally gave up. It was late and I knew we can re-run the task in the morning when I find the solution.

I logged off, talked for a moment t my little brother, made a tea... And then I knew where the problem was. I wentÂ back, checked... And it was right there, in the database!

How often do you feel stuck like this?

How often do you get stuck on writing a code to yet another feature?

You concentrate hardÂ to find a solution to the problem. ThenÂ after a while, you're so frustrated that you decide to grab a tea and rant how a bad day you have? Or you decide to fix a bug in the different part of the software? Then after some time, you come up with a solution that makes you jump back to write code for the first problem?

The psychologistsÂ call this impression of feeling stuck an impasse. And what comes after a break is anÂ insight.

You get stuck when you concentrate too hard

An impasse occurs when you concentrate on something too hard. It's counterintuitive. We were thought at school that to achieve something we struggle with we should try harder.

The anxiety inside you

When you're stuck you may feel it's wrong to take a break. You may think you'll lose momentum or the energy you used on solving the problem. As a result, you're getting moreÂ anxious because you can't finish the task at hand. You can even start doubting your problem-solving skills.

Take a break

It's important to take a break in times like this.

It's when you do something else that you have this 'aha' moment. Â The moment of sudden insight or discovery.

Here are some ideas to take a break without leaving the office:

listen to your favoriteÂ song-just listen, concentrate on the lyrics, the music, the vocalist
watch a youtube video with that song (or try another short video you just want to
write your name in few different ways
5-minute meditation
if meditation is not an option listen to a relaxing music and concentrate on the song
count close your eyes and count from 300 to 200 (or similar, but backward)
look out the window and think what the clouds remind you of
go to make a tea or a coffee
draw whatÂ was your dream job when you were 6
anything you can think of, that can grab your full attention for few minutes
talk to the duck ;)

How do you take a break?

Let me know what work's for you in the comments. I appreciate new ideas too!

And if you got stuck take a break!

Developer under time pressure ? work faster : work better

Aga Zaboklicka — Fri, 14 Jul 2017 11:55:46 +0000

Originally published on my blog.

//for those not familiar with ternary operator the title means:
if(isDeveloperUnderTimePressure()){
    workFaster();
} else {
    workBetter();
}

Mind reading and predicting future techniques aren't fully developed yet. So lots of software development projects are late. It get's better when the agile processes are successfully adapted but it's not always the case.

There's always more work to be done in the project than we initially predicted. Business needs change, we misunderstand the expectations, estimation errors can be also a case. There're lots of reasons something can go wrong.

"Improvement" ideas

Here're two common ideas supposed to help get your work done in time:

You put in more hours.
You compromise the quality of the product.
That's recipe for a disaster.

Overtime catch up

There might be some benefit in a few extra hours worked on Saturday to meet a Monday's deadline, but you'd want to catch up with your private life at some point.

Nobody can continually do creative intellectual work for over forty hours a week. Your effectiveness will decline sooner or later.

Compromise the quality of the product.

Imagine you have to implement new functionality. The manager stays over your head and tells you to work faster. Or tells you there are only 16 hours in a budget to implement the functionality.

Now, you can do it in a quick, but messy way or take your time to put in place a cleaner design. If you choose instant gratification in that step and implement the change quickly and not cleanly, you'll pay the price in the long run.

It's called technical debt. Technical debt is anything that should have been done as part of a development but wasn't. Those are unrefactored code, unresolved bugs, missing documentation, missed test cases etc.

Technical debt is like any other debt—you keep paying on it. Development time is getting longer. Implementation of new changes slows down because of debugging and hard to spot defects.

Don't cut corners. Improve.

Schedule pressure leads to cutting corners, overwork, and growing technical debt. This slowers delivery of valuable features.

Help to build awareness inside your team about those things and you'll see the great benefits in the future.

Inking and thinking in software project

Aga Zaboklicka — Tue, 11 Jul 2017 08:39:50 +0000

This post was originally published on my Jump Start blog

It's not the ink–it's the think

“It's not the ink–it's the think,” wroteÂ Robert Mankoff (New YorkerÂ cartoon editor), answering to the question how to get ideas for cartoons by people who want to submit them toÂ The New Yorker. "There really is no trick–you just have to think of them" he said.

It's the same in creating a software.Â

Turning Problems into Code

Writing the actual code is only a small part of the process. Opening IDE to bang out a solution upfront is rarely the case. First, you have to understand the problem and break in into pieces. After some time you will start to see the patterns and solve the problems without too much thinking about them, but even then the more complicated tasks will require quite a think.

Understanding the Problem

I like to write down the problem.

I draw it on a whiteboard or on a flipchart. It gives me space to think and write extra ideas or different approaches. I see the dependencies clearer this way. When working on the complicated task IÂ ask myself: What do I know about the system that it's about to be built? What should be built? What goes inside and what's the expected outcome? How it connects with the existing system.

In enterprise projects, you usually have user stories, requirements etc that help you answer those questions :)

Breaking complex programs into pieces

Smaller features are easier to manage. Easier to test. Easier to write. So think in small batches. Complex applications are composed of smaller programs working together.

Driving Design with Tests

Think of the result from the start is one of the best software development practices. Developers do this usingÂ test-driven development, orÂ TDD (see more in Google).Â

Writing the Code

Figuring outÂ whatÂ you want to write before you figure outÂ howÂ to write it seems an obvious first step. But many developers take a shortcut. They charge straight at the water and dive deep to get out of breath pretty soon.

Taking the time to design the program speeds things up in the further development. A poorly designed code is hard to maintain and extend.Â The untested, unplanned code in production, requires painful changes to it later.

And who likes to do the maintenanceÂ only?

How to avoid comprehensive documentation/ over-documentation?

Aga Zaboklicka — Wed, 05 Jul 2017 10:45:21 +0000

Hi!
I think one of the teams I work in is overdocumenting things. It's we do waterfall-like iterations (I work on legacy systems and we do both change requests and production support), and there is some kind of document written at every stage of the project:
1) collecting requirements - the first document
2) after the project was accepted - another document with the same requirements but with more details
3) than high lever design for the system - general architecture overview
4) than more detailed system design up to the point of describing code
It's pretty exhausting and I was wondering how to do it in a smarter way.
What are in your opinion best ways to do project documentation?
Or how to talk the team into more collaborative documentation? I'm not sure how to start the stone soup here...

Any automation tips/ideas?
For example, for the requirements, I'd like to create one document and extend it over time instead of writing the documentation from the scratch every time and duplicate the information...

Kanban board: the way to organize your work even outside the agile project.

Aga Zaboklicka — Mon, 12 Jun 2017 10:37:24 +0000

This post was originally published here.

My company uses IBM DOORS connector for JIRA to simplify requirements tracking process. However, the way requirements are transferred to JIRA from DOORS makes it hard to say what the requirement is about. So when I was looking for a way to view the actual requirement my project manager told me about a possibility to create a Kanban board in JIRA.

It took me a moment to actually pick up the tool - I used the old way coz I've got no idea how to set up the board, then I waited for permission from JIRA admin... The regular corporate way... But when I finally set up my first Kanban board I instantly fell in love. Really... (James, if you'll ever read this: thanks a bunch!)

So why to use a Kanban board even outside any agile methodology?

Even though the main purpose of Kanban was to view the requirements without opening them in a new tab the first thing I've noticed is that it's extremely easy to read and helps me manage my tasks without them going awry.

If you are interested what Kanban board can do for you (even outside the agile process and without JIRA) here are the pros of Kanban board:

Kanban board is based on a very simple idea. Its shows the workflow in an easy to read, visual way
Kanban enhances just-in-time management system (JIT) of producing only what is required, exactly when it is required and delivered exactly where it is required on time.
The board gives you a visual sign indicating you can start new work.
It helps you remember to start with what you do now and focus on tasks at hand.
It limits work in progress, so it keeps you from working on too many tasks at once.
When you look at properly set up kanban board you know the context of the task i.e. the deadline, project, dependencies, etc:
You can add as many columns as you want (The easiest is well-known SCRUM flow: TODO, In Progress, Done) but you can add fields such as review, integration, closed etc ;) Whatever you feel is needed so you can see what's in what stage of work.
You can divide vertical columns into swimlanes indicating, for example, the due date, story, project or whatever else you want so that you have your work divided into meaningful chunks instead of a long list of TODO tasks without the context.
You can customize task cards by adding colors to them - for whatever purpose you want ;)

Kanban board can be easily applied in any management system in the world of software development. I believe it helps you avoid mind wrestling with remembering what to do first and helps concentrate on important tasks so if you have a possibility try it, even if you're not a part of a SCRUM or Kanban team ;)

How to C.A.R.E. for a software project?

Aga Zaboklicka — Tue, 06 Jun 2017 08:31:26 +0000

We, software developers, tend to have some bias towards cutting edge technologies and, in a perfect world, we'd only use them. It's efficiency driven so that's great but sometimes we forget that the code we write is written first to benefit the human and only second for a computer to understand.

And that's why we should C.A.R.E. about things we do. And C.A.R.E stand for:

Communication
Assumptions
Requirements
Expectations

Communication

Some people may think that the job of the software engineer is just to write code. However, the fact is, a big chunk of our time is spent dealing with other people. So, even if writing code is the part of your job you love the most you still have to communicate.

Communication is tightly coupled with other three.

Starting with...

Assumptions

We all make them otherwise, we'll never have anything done. The problem here is that what's common sense to you doesn't always have to be a common sense for someone else. So it's wise to communicate assumptions you are making.
And it may be clever to do some fact checking by asking yourself "How do I know this?" before starting to work on something and make sure you are making the same assumptions as everybody else.

Requirements

From assumptions, you can go back and forth to requirements. This refers usually to customer requirements that are one way or another communicated to you. You are supposed to capture them and translate them into an app. Unfortunately, they may be for example vague or inconsistent. If you can't answer the fundamental question: "What do I have to do?" how are you supposed to do that?

Expectations

Requirements are often customers expectations but those aren't always the same. And not only your customer have expectations. You have ones. Your manager does. And same goes for everybody else you collaborate with. The main point here is to what others expect from you and explain what you expect from them.

C.A.R.E.

When we collaborate with others we have great opportunities and great challenges. And if we remember about those four simple words we'll deliver not only a well-written code but also take C.A.R.E. of a successful outcome of the project we work on and make other people happy.

This is reblogged from https://jumpstart.blog/