Cristina Ruth's RSS Feed

5-Minute Guide to Organizing Your Own Tech Meetup

Mon, 13 Jan 2020 12:49:59 GMT

If you've been wanting to organize your own tech meetup, here is a step-by-step guide on how I got started a year or so ago, combined with lessons learned I've had along the way.

The steps are as follows, and we'll go through each one in detail.

Does the meetup already exist?
What is your goal? Who is your target audience? What are your potential topics?
Who are the organizers of the already-existing tech meetups in your area?
Determine your event cadence.
Determine your event formats.
Determine your venues and food sources.
Build the "interested" contact list.
Create your meetup group and your first event!
Rinse and repeat and keep up interest.

Step 1. Does the meetup already exist?

It seems like an obvious question, but we just get so excited at concepts and ideas, that we don't do our research first.

Search through meetup.com for tech groups in your area and ensure that none already exist similar to the one you want to create. Sometimes, too, the tech meetups are harder to find and the names are not descriptive enough to know what they are about. As you find tech meetup groups that have a large member base, take note of them and their corresponding organizers as we'll need them in step 3.

Once we're sure that the meetup we want to create is unique in your area, we move on to step 2.

Step 2. What is your goal? Who is your target audience? What are your potential topics?

Each meetup group is different. What do you want to achieve with this meetup? Do you want to connect professional people who work in IT together in a social setting? Do you want to share knowledge with each other?

The more specific you can be in defining your goal and what to achieve, the better since this will help you define who your target audience would be. Who is the typical person who would attend your meetup events? What do they do? Where do they spend their time? What motivates them to attend your events?

As you answer these questions around your goal and target audience, it will help you define your potential topics because now, you have an idea of the ideal person who would be attending your event. What topics would they be interested in? Is it new technology, best practices, or other things?

Note all these down somewhere -- you'll need to reference them later as you plan and schedule your events.

Step 3. Who are the organizers of the already-existing tech meetups in your area?

Look through your notes of popular tech meetups and their corresponding organizers from step 1. Reach out to each organizer introducing yourself, stating you want to start your own (maybe include your goal and other details you've determined from step 2) and are looking for some tips -- maybe offer to buy them coffee and meet that way.

You may not get responses from all of them, but the more organizers you meet, the more tips you'll be able to get.

Some questions you can ask them that will help you with the next steps are:

What local companies offer venues and/or food for the tech meetups?
What other venue places do they use for their events? What is the associated cost for each one?
What are their event formats? Which are the most popular ones?
What other tips / lessons learned do they have to share?

Step 4. Determine your event cadence.

Organizing a meetup takes time. It requires coordinating with venues, local companies, and brainstorming various event formats. Take these into consideration when determining a regular event cadence for your meetup. Will it be monthly, weekly, bi-weekly, etc? If monthly, would be on the 1st, 2nd, 3rd, or 4th Monday, Tuesday, Wednesday, etc? What time would you generally have your events? Think through your schedule and how the meetup events organizing schedule would look like.

Having a regular cadence will help your members know ahead of time when your events are held and hold a spot on their calendar for your events.

Step 5. Determine your event formats.

Now that you know your desired event cadence, it's time to brainstorm some event formats you want for your meetup that are appropriate to your target audience. Hopefully, you've gotten some tips from the other tech organizers around this as well.

Some common formats are:

Talks. A speaker comes and talks about a particular topic, and then the audience can ask questions afterwards.
Lightning Talks. Multiple speakers come and speak 5-10 minutes around a common topic.
Workshops. Hands-on learnings.
Social. People gather around food and drinks and hang out.

Having a good mix would ensure your meetup doesn't stay too static and can keep up the interest of your members.

Step 6. Determine your venues and food sources.

Since meetup is all about meeting people in person, you would need a space to hold your events in with adequate space for the amount of people you'll have.

Hopefully, you'll have gotten a good list from the other tech organizers in the area, but if not, then you have some research work to do. Local libraries usually have meeting rooms you can use as long as your events are free. Reach out on social media/Slack communities for local companies who may be interested in providing you space for your events.

People like food, so bonus points if you can secure some food sponsors for your events. Make sure you set your members' expectations on whether there will be food or not at the events. From personal experience, it's harder to get companies to pay for food for your meetup, especially if you're just starting out.

Step 7. Build the "interested" contact list.

Now that you've got a plan, nobody knows your meetup exists. So we now have to do some advertising. I have no marketing background, so this was the hardest part I had to do when I was just starting my own meetup.

Create a Google form where you can collect emails of people who would be interested in your meetup. Share on social media something around, "Hey, I'm starting this group about X and Z. If you're interested, I can let you know when we have our first event if you fill out this form."

Bonus if you already have existing contacts in your area's tech community, because then you'd just ask them to spread the word. The other tech organizers may also agree to help you spread the word.

Step 8. Create your meetup group and your first event!

Once you have an adequate number of interested people signed up and you have an event venue secured, it's time to create your meetup group and your first event!

After you've scheduled your first event, send the link to the people who signed up from step 7, and spread the word on social media and other tech organizers and other meetup groups. A lot of meetup groups have the discussion board on the front page open to any comments, so you can also comment on there.

Step 9. Rinse and repeat and keep up interest.

There will be mistakes -- expect them! And learn from them, and apply any learnings to future events.

As I mentioned earlier, mix up the events every now and then to keep up interest of your members. If you're out of ideas, you could ask your members for topics they would be interested in.

Wrap Up

Creating your own tech meetup requires a lot of initial planning ranging from ensuring that it doesn't already exist to reaching out to other local tech meetup organizers on lessons learned and securing event venues and food. It also includes defining a goal and your target audience as well as an event cadence and event formats.

At the start, there will need to be a lot of marketing to help others be aware of your group, but once you start having your events, word-of-mouth advertising will help. Meetup also is a good platform that will drive new members to your group through their defined interests.

I hope this guide has helped you and I wish you all the best in making your new meetup group! 🙂

Other Resources

5 Ways Writing Documentation Helps YOU

Thu, 02 Jan 2020 13:25:46 GMT

When I first started my professional dev career, I hated writing documentation. I didn't think it was as fun as coding and so, I never took the time to write them.

Over the years, as my job responsibilities progressed, I realized how valuable writing documentation is and that, ultimately, doing so helps me.

What is Documentation?

Before we go any further, let's first clarify what documentation is.

Documentation is written "articles" or descriptions around a specific topic.

Documentation can be written for many things like:

Explaining the description of classes, functions and variables.
Explaining the "why" behind business logic.
Explaining how things in a system connect together. (i.e. diagrams of database connections and APIs and servers, etc)
Explaining how to get something set up. (i.e. getting a developer machine setup to enable development work for a given repository)
Explaining guidelines. (i.e. a standards documentation around variable naming and patterns to be used)
Explaining troubleshooting steps for common problems.
Explaining the high-level logic flow of a specific feature. (i.e. diagram flowchart)

And more.

As developers, we read documentation when:

Trying to install a "plugin" into our project. We then read through their "get started" documentation.
Trying to troubleshoot a bug, and we find our way into a "plugin". We then read through their "troubleshooting" documentation.
When we're looking into contributing to an open source project, we read through their "Contributing.md" documentation.
When we're setting up our machines to have a local working environment for an open source project, we read through their "Setup.md" documentation.

And more.

How Documentation Helps YOU

In this article, we'll walk through 5 ways writing documentation helps you:

Improve your writing skills.
Help yourself in the future.
Help your teammates.
Free your time.
Help yourself stand out.

1. Improve Your Writing Skills

Writing skills are applicable to all aspects of your life. You need writing skills to be able to efficiently communicate the message you want to deliver. This applies in everything -- from your personal life to school to your career, any career.

The more documentation you write, the more you hone and improve your writing skills.

2. Help Yourself in the future

That code you write and how it all works together, as well as all the business logic around it and how everything is connected -- that context WILL be gone in just a few weeks of not working on it.

When you have multiple codebases to touch or large codebases with multiple various complex functionalities, each piece will have pick-up time which will take a lot longer without documentation. (Pick up time is the amount of time it takes to be able to understand a given task and start making progress to finishing it.)

I've personally found that writing the supporting documentation on what I've done helps me a couple months in the future when I have to touch the project again.

If it's code you know you will not touch for a while but will need to come back to, it may be worth the time investment to write the supporting documentation for it.

3. Help Your Teammates

As we discussed above, code is complex and pick-up time takes a lot longer without written documentation.

If you work in a team environment where your code will be worked on by some other developer, then it would be even harder for them to pick up the context without written documentation.

By writing supporting documentation on the what you've written, you're enabling your teammates to be more productive.

4. Free Your time

Have you ever gotten a meeting invite asking how things work? 🙋‍♀️
Have you ever gotten emails asking how to do a particular task? 🙋‍♀️
Have you ever gotten emails asking why something works a particular way and it's the same answer every time? 🙋‍♀️

Ever since I've started writing supporting documentation, I have had less meetings and emails around how things work/how to do things.

If I encounter a meeting invite around a topic that isn't captured in the documentation, I create the documentation before the meeting if I have time, send it to the meeting requestor, and ask them to meet with me if the documentation is not suffice. If I don't have enough time before the meeting, I write the documentation afterwards because I know it will save me meeting time in the future.

I start a FAQ documentation on how to do specific tasks and around questions that have the same answers. I then point people to these when answering emails. Now they know in the future where to go to get their answers. If they do forget, it takes me much less time to give them a link to the FAQ documentation.

5. Help Yourself Stand Out

If you help others be productive by writing documentation, you will set yourself apart and stand out.

I've worked with a lot of developers, and few take the time to write documentation. So I am very appreciative when I encounter the ones that enable me to be productive because they took the time to write up supporting documentation, and it also saves me a meeting request.

By writing supporting documentation, you set yourself apart and enable others to be more productive. In my experience, developers who help others be more productive are the ones who get promoted.

Documentation Caveat

As with all things related to software development, documentation takes time and effort. Therefore, it requires some time management.

There would be situations where there would be no time to write documentation due to critical project timelines.

We, therefore, need to be cognizant of when it's appropriate to invest in writing documentation, and when it's not.

Wrap Up

Writing documentation helps you enhance your writing skills while enabling yourself and your teammates to be more productive. It also saves you time from meetings and emails in the future. By enabling others and having good written communication skills, you highly increase your chances of getting promoted.

But we also need to realize that it takes effort and time, and we just have to also be aware when it makes sense to write it, and when it doesn't.

11 Things to Consider for More Accurate Developer Estimates

Mon, 23 Dec 2019 15:10:57 GMT

If you've been asked to do an estimate before, you'd agree it's easier said than done.

The bigger the scope (how much to be done), the harder it is to estimate because the complexity increases and therefore, the ambiguity and unknowns increase, and the more room there are for bugs, mistakes and miscommunication.

Types of Estimates

High-Level. At this point, our business partners/clients just want to understand the total effort required for something they are considering doing. They want a gut estimate, something that takes a few seconds to estimate. They don't want much time spent on even just estimating because they are not sure yet if it's worth the investment.
Detailed. Detailed estimates are when the project has already been vetted and our business partners/clients want a more accurate estimate on what it would take. We can then take the time to analyze it a bit more so we can come back with more defined tasks and a more defined timeline.

In my experience, high-level estimates are used a lot more because they apply to a lot of things, and not just to estimate a project effort. They are also used to quick estimate features and bugs for easier prioritization on which ones are to be focused on.

I've also found that I only do detailed estimates at the start of a just vetted project to help identify the various pieces and estimated timeline and effort of the project as a whole.

Since high-level estimates are done a lot more times than detailed ones, this post will then focus on the things I usually consider when doing high-level estimates.

Overview of Things to Consider

When providing a high-level estimate, here are all the things I consider in my head before giving an answer. We'll go through each one in detail below.

Identify the various pieces.
My and my team of developers' familiarity with all the pieces.
Impact on existing functionalities.
Time to communicate and organize daily task progress and coordinating with my team of developers as well as our business partners/clients.
Time to write unit tests.
Time to write integration tests.
Time to manually test.
Time to log bugs, triage them, prioritize them, and retesting them.
Time to document what we have done, especially if it's a major effort.
Time to log bugs, triage them, prioritize them, and retesting them AFTER going live.
Time to train support operations staff to support the new functionality.

Depending on the thing we're estimating (project, feature or bug), not all of the above may apply, but I do go through this list in my head no matter what I'm estimating.

1 - Identifying the Various Pieces

Even in high-level estimates, a gut design on how the pieces work together will form in our heads of what it would take. Taking that design and breaking it down into multiple pieces then helps us identify the complexity.

What are all the various pieces involved in the work that is to be done?
How many systems and codebases are we touching?
How many APIs are we going to call?
Which databases do we connect to, if any?
What are the frameworks/plugins/architecture/packages/patterns that we need to use and/or apply?

Since this is a high-level design, we can only use what we know of the systems. So familiarity helps provide more accurate estimates. Which brings me to my next point.

2 - Familiarity with all the Pieces

With all the pieces we were able to identify, what is our familiarity with all the pieces?

I usually work with a team of developers, so for a safer estimate, I usually assume that majority of them, including myself, will not be familiar with everything.

I usually consider familiarity around:

Codebases and structure
Database schemas
Architectural patterns
APIs (is it a new API we're going to be using)
Vendor solutions

I then account for time to learn -- reading the documentation, researching and even coordinating with a knowledgeable resource. A lot of times, there are multiple knowledgeable resources, one for each piece we are not familiar with.

3 - Identifying Functionality Impact

This thing that we are estimating -- is it a new functionality? Or is it updating an existing functionality? If so, then is it a core one that would impact multiple other functionalities when updated?

Knowing this answer will help us gauge our overall testing effort. The more existing functionalities are impacted, the more testing we will have to be doing (i.e. regression testing).

If your impacted functionalities have already existing unit tests and integration tests, then we'll also need to consider the effort to update existing unit tests and integration tests as needed. Having existing unit tests and integration tests will definitely help reduce the overall testing effort, because these will cover part of your regression testing.

4 - Communication and Organization Overhead

We'll also need to consider communication time and organization time to sort and execute through our daily tasks.

How much time would it take to organize through the tasks that we need to get done?
How much time would it take to provide updates to the team of what we got done, what is in progress, and what we're going to work on next?
How much time would it take to coordinate with the knowledge resources to get the information we need to complete our tasks?
How much time would it take to coordinate with my team of developers and answer their clarification questions?
How much time would it take to coordinate with our business partners/clients to clarify requirements and prioritize features/bugs?

Executing through a project requires a lot of communication between me, my team of developers, our business partners/clients, and our stakeholders. Communicating is part of the work if we want to ensure building that trust relationship with the people we work with.

5 - Writing Unit tests

If we're writing new functionality, and we've established that they are worth writing unit tests for, then we need to accommodate for the time to write them.

Similarly, if you develop using TDD (test driven development), then your work effort will include this as well as the solution is developed.

6 - Writing Integration Tests

If your team invests in integration tests, then these may need to be written as well.

7 - Manual Testing

Despite unit tests and integration tests being present, there is still manual testing that needs to be done.

The less unit tests and integration tests you have, the more manual testing that will need to be done.

This includes the initial manual testing done when development is complete. But, I also include the manual testing required each and every time a bug is fixed, or a code change has been introduced due to shifted requirements.

8 - Bugs and More Bugs

So we've written our automated tests and have done our manual testing. During our initial manual testing phase, it is highly likely that we will find bugs.

Depending on how many bugs are found, there is effort to sort through them, triage them, prioritize them, fix them, test them and coordinate with the team on their status.

Worse, bug fixes can introduce more bugs so typically, bug fixes also include regression testing to ensure nothing else got broken.

9 - Updating Documentation

If your team is invested in creating/maintaining documentation, this is also additional effort.

Consider the size and complexity of the solution and how much the documentation needs to be updated/created.

10 - Stabilization after Going Live

Despite all our testing efforts, we can only test so much scenarios ourselves. Our real users and real data puts our solution to the test.

During this time, we are in bugs and more bugs stage again, but uncontrolled and in the hands of our users.

11 - Handing Off to Operational Support

For some teams, operational support (incidents when things are down/not working right, fixing production bugs, upgrading dependencies like servers, databases, plugins, etc) is handled by a different team.

If this applies, then there is also additional effort in handing this off to the operational support team, and likely a duality will be present wherein there will be a time period where you and/or your development team will provide some support to the operational support team as they learn the solution until they can handle majority, if not all, of the problems/support questions that come through.

Wrapping Up

Developing solutions not only includes development time, but analysis, communication, testing and stabilization.

The larger the change size, the higher the complexity and the more difficult it is to estimate. Ambiguity and unknowns also increase the estimate because they also increase the complexity.

The more detailed we can be when doing our estimates, the better our estimates will become.

4 Steps To Grow Your People Skills

Wed, 11 Dec 2019 11:01:46 GMT

Talking with people is not easy. 6 years ago, I was immensely shy and found it hard to talk with people. Today, I give talks at conferences.

In this post, I share my history, my journey, my learnings, and outlined them to 4 steps where YOU can do it too.

Then and Now

6 years ago

I would rather code all day than to talk with people.
I focused on myself and only worked people if I had to.
I pretended I was busy with my phone or something else when I found myself in an elevator with a stranger.
I clammed up when speaking in front of a lot of people.

Today

I actually like talking to people. In fact, I start feeling sad if I spend too many days coding by myself.
I focus on others and continually seek out new people even if I don't have to work with them.
I say hi and chat about the weather, or what's currently happening, with a stranger in an elevator. I also smile and say hi to people I "meet" in the hallways.
I can talk comfortably in front of a lot of people. I still get nervous, but it's way easier now.

What Happened?

The first couple of years, I think it was mainly due to increased job responsibilities -- becoming more of a lead/senior dev. As part of that, I had to interact and talk with people a lot more. I had to clarify requirements, ask questions, set expectations, coordinate with testers, etc.

Over the years, I learned to "banter" and "small talk" through trials and errors and practice -- lots of practice.

Then, a few years ago, I read a couple of books (mentioned below) that radically changed my view from me to you -- and genuinely caring for others, their needs and listening.

It was hard but after reading those books, I actively tried doing things that I was super uncomfortable about -- like...

Saying hi to complete strangers
Speaking in front of people
Making small talk
Finding topics to talk about, and
Keeping conversations going

There were a LOT of cringy and mortifying moments like...

OMG. That did NOT go well. So embarrassing!

But despite those, I still kept on trying. And trying. And trying. And telling myself:

OK. That was not good, but let's focus on what YOU can learn from this and learn what NOT to do next so we can improve!

And somehow, suddenly, I realized that I can talk with people better and I can talk in front of people better. It's easier! Note the er. It's still hard, but it's not as gut-wrenching as I found it before.

How You Can Do It Too

Note: This section does not contain affiliate links.

1. Read the Book "How to Win Friends and Influence People"

How to Win Friends and Influence People by Dale Carnegie

This book helped me focus on others instead of myself, and oddly enough, by focusing on others, I have actually benefitted more by forming more genuine connections and had a huge part in earning me a promotion.

If you find yourself struggling to talk with people like I described above, give this book a shot and see what kind of learnings you can take from it. Check your local library if they have a copy. Take notes as you read. Make a cheat sheet for your reference for your daily life.

2. Read the Book "The 7 Habits of Highly Effective People"

The 7 Habits of Highly Effective People by Stephen R. Covey

I honestly thought this was a productivity book. Little did I know that it contained lots and lots of life lessons within. One of the biggest lessons I took from this book was:

Seek first to understand, than to be understood.

This is huge when talking with people, especially conflicts, which is inevitable in any relationship, personal or professional.

This book enhanced the learnings I got from How to Win Friends and Influence People, and taught me more about relationships, both personal and professional, as well as teaching me how to determine what I really want and then take actions on those wants/goals.

If you'd like to further improve your relationships, as well as learn how to set your goals and take action, check your local library and see if they have a copy. Take notes. Make a cheat sheet!

3. Apply Your Learnings

Keep them small -- one thing you can do for that day. And then make sure to celebrate that you tried! No matter the result -- whether you succeeded or not. Be kind to yourself, and help yourself through this. Change is hard. But it only will happen through persistence despite hard times. Learn from your mistakes and you will eventually succeed!

Some small things I tried that you can try too:

Say hi to a stranger.
Remembering to ask a person who asked how I was - how are YOU?
Remembering to listen to the other person I'm talking to. Instead of thinking and thinking on what I am going to say next.
Strike up a conversation with a random stranger.

A tip I read somewhere I found really helpful when talking with random strangers is to comment on something you both are experiencing OR having experienced. This is why the weather is such a common small talk topic! We all are experiencing the same weather when we're in the same physical space. A similar conversation starter is asking how their conference experience is so far (if you're attending a conference)

4. Go Bigger

When you've done the small things above consistently to the point that you got better, you'll just randomly realize that you are better at interacting with people. It's just a bit easier than it was before.

Keep challenging yourself at this point. Keep practicing. Go bigger.

Some big things I tried that you can try too:

Submitted and presented talks for conferences.
At conferences, sat at tables where complete strangers were sitting AND talked with them.
Joined in in-progress conversations where people were already talking.

This is definitely scarier. I did my first big conference talk in September this year, and I was nervous! It's very different being up in front of a bunch of people rather than just talking in-person with 1 or a few people. My instinct was to just quit and stop because it would be easier to do that.

But if I had done that, I would not have been able to give my talk. I would've not been able to grow.

My talk went fine -- I felt really awkward -- but I had chosen a topic I knew by heart and so, talking about it, the words just came flowing out of my mouth. It was easy to talk about it because I knew the topic so well.

And I celebrated that I did it. That I tried it.

It is so important to celebrate our small wins, and celebrate the fact that we just tried it. You can do it too!

Summary

I'm still not perfect in talking with people and I will never be and that is perfectly okay.

You will never be either and that is also perfectly okay! Just keep learning, trying, practicing and celebrate your small wins. What matters is that you are better than how you were before.

Other Resources

Crucial Conversations Tools for Talking When Stakes Are High by Kerry Patterson, Joseph Grenny, Ron McMillan and Al Switzler - I found this book helpful on dealing with conflicts with people and being able to navigate those conversations especially with emotions run high. After you've read the other books above and want more, this is another book that can help you hone those people skills.

14 Soft Skills You Need To Be A Successful Developer Consultant

Tue, 03 Dec 2019 19:18:59 GMT

As developer consultants, we generally work with clients, majority of whom are not technical, to help deliver a software solution to their problems.

It's not always easy because technical skills alone would not result in a happy client, and I was curious what key skills you need to have to be a successful one. So I chatted with a couple of other local Madison devs and we discussed what we think these key skills are.

Below is a summary of our key points and our chat log behind each one.

1. Learning

Having the ability to learn and how fast you learn will impact your consulting relationship with your client. There are many things to learn like the client's business, their needs/problems, who knows which, even their codebase and tech stack. It's similar to adaptability, and certainly having a positive attitude and I can do it attitude will help you tackle all of the things that need to be learned and adapted to.

Steve: An employee is expected to have some ramp-up time to absorb the stack, the company, the culture, etc, but a consultant is expected to be productive as quickly as possible. That means the entire engagement depends on the consultant learning as much as possible as fast as possible -- understanding the client's business, their needs, their problems, how to get results from other people in the company, who to talk to for what, etc.

Cristina: Ah so can this also mean adaptability?

Steve: I think there's a lot of overlap there

Cristina: Yeah, I think a positive attitude is also key here

Cristina: There's a lot of things to tackle

Cristina: Having an "I can do it" attitude will keep you resilient in all the things that need to be done.

Steve: Definitely. It's also a great way to build exposure to a wide breadth of things. The "sure, I'll take that on" attitude keeps you relevant as technology and the business keep moving forward.

2. Ability to Listen

Listen to your client, ask further questions and read between the lines to determine if what they're asking for really would meet their needs. A lof ot clients come with assumed solutions already in mind and part of the consultant's work is to ensure that the client gets the appropriate solution that fits their needs.

But it's tricky. While doing this, you have to be careful on ensuring the client still feels heard and does not feel arrogance coming from your end.

Bo: You have to be able to listen very carefully hear to what your client is really asking for versus what he/she may be asking for at face value. "Listening" encompasses asking good questions.

Cristina: Oh, yeah, reading between the lines!

Steve: That's a good point. Clients usually assume you know all about their business and general things about their problem. Sometimes getting results means putting on the deerstalker hat.

Bo: Example: we've learned the hard way that clients don't always really know what platform (!) they should really be targeting. We've built web apps that the client later decided should be mobile, and vice versa. More careful inquiry, poking and prodding at the early stages, versus, simply taking the ask at face value would have saved both of us time & $.

Cristina: And also, the client needs to feel that they're actually heard right?

Cristina: It's a careful line to listen between the lines and making the customer not feel like they're heard and just sensing arrogance from the consultant.

Bo: def

3. Expectation Management

Setting expectations applies not only to customers/clients, but also team members, bosses and executives. It can also apply to your personal life, like with a significant other, a friend, a child, a parent, a relative or an acquaintance.

Ensure they know what to expect from you so that you can manage and build their trust in the relationship. This means a lot of proactive communication, and asking clarifying questions if you are not sure about something.

Cristina: So by Expectation Management, I mean that developers should be able to set expectations with customers and teammates, if applicable. This means, letting them know what's coming next, what to expect, what are the good things, what are the bad things.

Cristina: Wrong expectations would result in people getting upset because expectations weren't managed well enough.

Cristina: For example, I am working with a customer and they asked me to develop something.

Cristina: If I didn't manage expectations well, I would say I'll get this done within a week.

Cristina: If I did, I could say that I need more information, and some time to research, and I don't know the exact timeline yet.

Steve: I've found this to be crucial for building trust with the client

Bo: Managing client expectations is hugely important, and not always easy.

Bo: so — yeah, good one.

4. Negotiation

As mentioned, clients/customers can have specific solutions already in mind, and sometimes, that means asking for impossible things. This short youtube comedy sketch demonstrates how difficult that can be. Being able to counter and negotiate their asks while keeping that trust in the relationship will ensure the client gets what they really need.

Cristina: Customers can tend to ask for impossible things. Having the ability to counter their asks and explain things in a way that they can see the benefit to them, can mean $$$ saved for the customers and more efficient solutions.

Bo: good one also

Steve: This is a good one but also difficult to master. I have not 😟 but my go-to tactic is to find a win-win-win by understanding what's driving the client.

Cristina: I don't think anybody would ever master this. It's so hard!

Kendell: I've found while consulting for Horticulture, before switching to tech that self worth is a big part of negotiation. That way you don't feel guilty asking for a deal that respects your time & financial expectations.

Steve: Somewhere I read that negotiation should always be approached from a position of power - even if the only "power" is that you can walk away.

Cristina: Hmm.

Cristina: Doesn't sound quite right?

Cristina: In a consultant role, you don't have that position of power

Steve: I think it depends on the individual. I was sent to a client recently and found the manager to be an absolutely terrible person, and it was very bad for their dev team. I informed my boss I wouldn't be returning and felt the moral situation strong enough to say my employer could either keep me and not send me back or lose me. A couple of weeks later the manager was let go.

Cristina: Wow

Cristina: I'm glad to hear you have your employer support on this one

Steve: Everything's shades of intensity, but if the worst case happens, there's always another job

Cristina: I think that's easier for people with years of experience on their belt

Cristina: It's hard for someone who's just starting out. their bargaining power is pretty low

Steve: I think there's a bell curve. Having no experience definitely lessens that power. 3-6 years of experience is where the power maximizes because that's where the highest number of positions are. 7+ reduces in power again because the number of options becomes more limited.

Cristina: Wait. interesting. Why do you think 7+ reduces the power?

Steve: But in the end I see it as being about self-respect. Gotta eat Ramen for a few months to get out of a toxic job? Do it.

Cristina: Harder for people wtih families though. Especially if you don't have the backup savings to not really care about keeping your job

Cristina: Still curious why would 7 years of experience reduce the number of options

Steve: IMO it's a function of specialty and salary. 7+ years usually means you're in a niche or deep in a specific industry or set of technologies. Shifting to a job in a different area would require taking a pay cut because you're basically the equivalent of someone with 2-3 years of experience in that area. Not many people are willing to take that drastic of a measure (though we have seen several recently at my company).

Cristina: Oh, good point. didn't realize that.

Steve: Family/savings as a limiter is definitely true, but there are always other jobs. TekSystems will take anyone who hasn't been a zombie for more than four or five months.

Cristina: True, but the quality of the position would be questionable right?

Steve: Oh, undoubtedly, but if it's just a temp position while searching for a "real" job, it's a way to pay the bills/support the family until something better is available

Cristina: True enough, good point

5. Explain Technical Concepts

When going to the doctor and they bring up a medical term about what you have and does not explain what it is, do you find yourself getting frustrated?

In our technical software world, a lot of terms are jargon. We get so used using them every day that we forget which words are jargon. When working with clients, we need to be more aware of the terms we use, watch for confused facial expressions, and be able to explain them in a non-condescending way to ensure and keep that trust in the relationship.

Recently, our cat had to have a lot of tests because they felt her kidneys were larger than normal during her last physical exam. Throughout the process, the vet explained everything in layman's terms that I could understand and I was very appreciative of that.

Cristina: Having the ability to be able to explain technical concepts to people who don't understand them will set a consultant apart.

Cristina: Think explaining CORS to a customer, and being able to explain it more with relatable common objects where non-technical people can relate. Or explaining technical debt. Being able to do so will help convince customers of concepts you want them to do. 🙂

Steve: We see this often as many of our clients have a vague idea for their business but know nothing about tech, electronics, materials, or design. They get frustrated if we can't explain why building their thing has a line item for user account management or whatever.

Bo: Yep, doing so in a way that client doesn’t feel stupid . I have a hard time keeping up with concepts and esp their acronyms in parallel techs all the time. And things change so fast..

Cristina: Yeah, very key! If you explain it in a condescending way, then you're destroying that client relationship trust

Steve: Ooh, I'm going to run with that one

6. Agnosticism

As consultants, our role is to solve our client's problems in the best way that we can. We should then be careful to pick the technologies for our solution that best fit our clients, and try to avoid using the technologies just because we really like them or would like to play with them.

Bo: It’s easy to get married to a favorite tech or toolchain, but it may not always be the best fit for your client. One size doesn’t always fit all..

Cristina: OOOOH!!

Cristina: I love this one

Cristina: Choose the tech that's best for the business/client/users rather than your favorite ones.

Steve: Nice one! Some clients already have their stack embedded in stone, and being unwilling to conform can lose the business or make the project a lot harder.

7. Organization

Software is complicated. There are a lot of tasks, requirement clarifications, bugs, steps to implement, etc. The better your organization skills are, the better you'll be able to keep track of outstanding tasks, which ones need follow up, map out the big picture, and prioritize which tasks are critical to be done now. Being able to do these would result in efficiency and therefore cost less $$$ as the project progresses.

Cristina: Organization skills can help you keep track of all the things that need to be done TODAY vs LATER.

Cristina: It can help you keep notes of what was discussed with clients, past decisions and paths forward.

Cristina: Knowing what can be done TODAY vs LATER will also help keep you focused and know when to set expectations and communicate with your client;

Cristina: Being focused would mean efficiency in spending $$$ therefore reducing cost.

Bo: +1

Steve: Nice. It also contributes to building an organized project - setting appropriate priorities (e.g. critical path items) and focusing on what the client requires sooner rather than later.

8. Realism

We all would like things to go as best they could, but this is not always the case, especially in our software world where there is a lot of ambiguity. So being able to have a realistic lens on can help with expectation management and also help build that trust relationship with your client.

Bo: This maybe overlaps with several of the other ideas, inc. Expectation Management — but this also might be one of the areas I’m personally worst at. For instance, building out realistic timelines — I find I’m almost always way too optimistic, even after doing this kind of thing for a long time…

Cristina: Hmmm Yeah, it's related but different also. I think we all want to be optimistic but reality doesn't quite let us achieve that desired timeline

Cristina: Communicating the reality also to clients can be tough

Bo: yep & yep

Steve: re estimating, I triple my worst-case estimate and they're dead-on. Not joking - at the end the estimate is always within a relative handful of hours of the actual work.

Cristina: Estimating is hard. It also depends on how well you know the system if the system exists already.

Cristina: If it's a new system, then there's even more unknowns in terms of integrations with new/existing technologies.

Steve: It's definitely more art than science!

9. Empathy

Being able to understand your client and be able to see things from their perspective will help you better solve their problems and also help build trust. Empathy not only plays a role in your client relationship but in all aspects of your career like building trust with coworkers, or building trust/keeping morale with your team of developers.

Steve: Really just a facet of client relations - understanding the client's motivations, situation, desires, limitations, etc from their perspective provides not only an alignment of purpose but also builds trust

Cristina: oh yeah. And in larger projects, if you're a lead of other devs, empathy also plays a role in your team being efficient because your team's morale would be higher.

Bo: I think this also goes for your clients’ users too — kind of an extension of what I was trying to say about Listening

Cristina: Very nice point about the users. Too often, we end up forgetting about the end users

Steve: Agreed, part of satisfying the client is making them look good to their clients

Steve: Feed the Elephant theory extended a level

10. Business Understanding

We developers can get really technical and love to solve problems with code. But we have to remember that ultimately we are developing solutions for business reasons. Along with empathy, the more we understand the business, their priorities, their goals, their needs, the better we are able to solve their problems.

Cristina: We develop software for businesses!

Cristina: The more we understand that business, their processes, their customers, and their needs, the better the solution we will end up creating for them.

Steve: This one is high on my list. There are lots of projects that are just clean-up jobs because someone wanted to try some new technology or do something they hadn't done before. At the end of the day devs are responsible for making money for the business, not satisfying an itch.

Cristina: Too many a times I've seen devs develop solutions because it's a shiny new tech. The business $$$ should be the end goal, not to play with new tech.

Cristina: Can always play with new tech as part of a hackathon or something.

Steve: Or just because it's a Saturday! I ported my ping-pong scoring system to a Pi 1 the other day because my laptop died. Learned about changing expectations (the Pi 1 was amazing in its day, but no longer "fast")!

11. Out-of-the-Box Thinking

Sometimes, we get too stuck in our way of thinking because we're just too close to the problem. There is value in seeking perspective from outsiders outside of the box, listen and consider their points of view.

Bo: sometimes the inspiration for an innovative approach to a problem comes from a completely different discipline or field

Cristina: Good one! It's so easy to get into this. This is why I often seek out non-team devs on opinions because it's so easy to get too in the box.

12. Documentation

Documentation is not fun, but it does really help because we're building a product and documentation is the piece of booklet that we get when we buy something from the store that needs to tell us users how to operate it.

Similarly, the software we're building is a product, and we need to build a manual to tell other users how to support it. For software, other users = the client/business owner and other developers who have to either add to it, or fix some bugs.

No documentation also usually means bottlenecks because only 1 resource knows how it works, and bottlenecks significantly slows agility.

Bo: a no-brainer, but often a place where freelancer’s esp cut corners — after all, the client usually doesn’t care (at first!) if the code is well documented and organized

Cristina: Also, selling this as a key need to the customer

Cristina: Of course, need documentation to operationally support the software you've built

Cristina: How will YOU know how it works in the future, or even worse, some other dev who did not build it?

Steve: This bites me every time I revisit old personal projects

Cristina: Ha. Me too. Biting me already on a personal project of mine.

Steve: I...may have lost the source code for an executable I want to make updates to. That might ok because there weren't any comments in the code to start with.

Cristina: Organizationally, we have bottlenecks because of the lack of documentation

Cristina: only some specific people know how X works

Cristina: so, then, only those people can work on X

Steve: Ahh, yeah. We just dealt with a client who was all .Net except that one critical microservice that someone decided to try out Python on (and document nothing)...and then he left. So they keep hiring people to figure out how it works, saddling them with the microservice for a while, and repeating it when they quit.

Cristina: Whoa lol

13. Stewardship

As consultants, we need to keep the client's best interest. Steve says it best in the chat log below.

Bo: 👍 good one

Steve: Consultants are responsible for spending the client's money wisely. There are lots of ways that can manifest, but it comes down to acting in the best interest of the client at all times - even if your employer wants you to do otherwise. A trust relationship is paramount in consulting, especially in a small town like Madison.

14. Flexibility

As consultants, we also need to be flexible on what can or cannot be done. We can negotiate as much as we want, but too much negotiation can turn our client relationships sour. We need to choose our battles wisely, and to know which ones to let go.

Cristina: While it's important to negotiate with clients on what's right, it's still important to be flexible if the negotiation doesn't work out.

Cristina: Don't get too stuck on your opinions because ultimately, the customer being happy is what matters and if we remain stubborn, then customers will just get frustrated and we will NOT get anything done.

Bo: def

Wait, where are technical skills?

As consultants, we definitely need technical skills to be able to build technical solutions for our clients. We all agree they're required.

However, Steve brings up an interesting point on how some employers actually didn't care if the candidates could code, they just wanted someone they could train to code.

Cristina: I mean, I'm not surprised, but none of our list involves technical skills.

Cristina: It's of course a given that you need technical skills to be able to consult successfully.

Steve: Technical skills can be acquired through on-the-job training, but interpersonal/business skills are more artsy and nuanced

Steve: I've had employers who didn't care if candidates could code, they just wanted someone they could train to code

Bo: Right, maybe a discussion for another day — the skills / disciplines that one needs to code etc don’t completely overlap those that are needed to consult

Steve: I think a lot of valuable consulting skills are also valuable manager-ing skills

Summary

To be a successful developer consultant requires not only technical skills, but a myriad of soft skills (interpesronal/business), which are harder to master. But as long as we're aware of them and continuously try to improve, then we're already doing better than how we were before.

Comic: The Lost Kitty

Fri, 29 Nov 2019 23:54:07 GMT

Randomly wrote this comic and wanted to share in case anybody would like it. 😄

Staying Sane and Organizing Family Life Craziness

Fri, 29 Nov 2019 03:55:30 GMT

Family life. Craziness! All. The. Time.

Chores. Doctor appointments. Menu plans. Food management. School events. Errands.

I recently stumbled onto bullet journaling and took the idea to handle all our family craziness.

I've been struggling for the past years on handling all what needs to be done and have tried multiple apps from calendars to TODO apps. It works at first, but then it starts getting TOO busy and we start getting overwhelmed.

As a software engineer, I LOVE tech but I'm realizing more and more that it really is difficult to completely replace pure pen and paper. Code is complicated and updates therefore take time. But with pen and paper, updates to your process are so easy to make -- all you need is a new sheet of paper and you've got your new process just like that.

I draw up a 8.5"x11" weekly spread for our family. Our needs were:

Keep track of the morning chores/reminders/TODOs.
Keep track of our spending. $$$
Keep track of our evening chores.
Keep track of our regular daily/weekly chores.
Have a separate TODO for the kid coz she's pretty independent and she's , quote, "starting to get tired of being told what to do." I understand and would love to not to anymore, so this is a new thing we're trying for December 😀
Have a FOCUSED area for each day for any day-specific appointments, events, reminders, and tasks.
Keep track of what's in our fridge to prioritize older food and save $$$ and reduce food waste.

So below is what we've come up with for December.

So then, here is how we use it:

We print out 4-5 copies, 1 for each week.
On the weekend, we cross-reference the digital family calendar and start filling out each day accordingly, with the bullet journal key system of square for tasks, triangles for appointments, circles for events, and stars for important items.
We cross-reference our family bullet journal future log, where we have noted other tasks/events, and note them down also.
We then put the sheet up on the fridge with magnets, where all family members can see it!
Each day, we then just reference things on the right side for our daily chores/tasks, with the appropriate column for the day that we are on. And we also reference the current day accordingly. We then fill in the squares with our specific color (black for me, blue for my spouse, and pink for our daughter) as we complete each task to indicate who completed them. For tasks that do not need to be done, an X is marked inside the square.
When we come across things that need to be done during the week, we just note it down on the paper. If it's for a date past the current week, we note it down in our family bullet journal's future log.

We've used this system since late October and it has worked really well! We've got a lot more visibility across me and my spouse on things that need to be done, what craziness is going on that day and/or that week, and who's done which.

Would you like to try the same thing to handle your family life craziness? I hope I've inspired you to try and do the same thing for your family. 🙂

How to Use Your Custom Domain with Your Site on Netlify

Wed, 27 Nov 2019 02:47:46 GMT

Purchase Your Domain

If you don't already own your domain, purchase one. Personally, I prefer Google Domains.

Manage DNS CNAME Record

Within Netlify, go to the site you want to add a custom domain to.
Click the Domain Settings button.
Under the Custom Domains section, click on Add domain alias button.
Type in your domain as www.yourdomain.com and click the Save button.
Your new domain should now be listed in the Custom Domains section, but you will see that next to it is a warning sign with the text Check DNS Configuration. Click on that text.
A DNS Configuration window pops up telling you to point the www CNAME record to Netlify.
Go to where you purchased your domain and find a way to manage the DNS settings. If it's in Google Domains, then go to domains.google.com and go to their DNS settings via the menu on the left.
Near the bottom of the page, under the Custom resource records, scan it to see if there is any existing CNAME entries. If so, either update that or delete it.
Add a new CNAME entry with the following values:
1. Name: www
2. Type: CNAME
3. TTL: 1H
4. Value: the-value-netlify-gave-you.netlify.com

DNS records can take up to 48 hours to propagate. So check again in about a day in the same Custom Domains section and see if the text next to your custom domain has changed to something around Check nameservers.

Update Name Servers

Click the text and Netlify will show you domains to use as nameservers.
Go back to where you purchased your domain and again, go to the DNS management settings. Within domains.google.com, we go to DNS settings and then the Name servers section.
For domains.google.com, we click on Use custom name servers, add each domain that Netlify gave us (example is ns2.netlify.com), and click the Save button.

Since this is a DNS change, it can take up to 48 hours to propagate. So we play the waiting game again. Check again in about a day or so. When everything is working right, the Netlify DNS text will show up next to your custom domain.

SSL

BONUS: Netlify automatically gives you a free SSL certificate even with a custom domain. This allows users to access your site via https and keeps browsers from throwing users a warning around your site not being secure.

You can check this by going to the SSL/TLS certificate section. It may take about a day again for this after you complete the name servers setup.

And You're Done!

Now, you've got your custom domain on your site. Yay!

Old Tech to Shiny New Tech: Strategies on Upgrading Your Code Without a Big Bang

Sun, 24 Nov 2019 22:58:59 GMT

Over the years, old code gets harder to maintain, and we start missing out on new capabilities and features from new technology. But, resources are usually limited, and we don't usually get around to doing these upgrades. How do we convert an app, like WebForms, to an MVC app on a limited budget and shippable increments without major issues?

In my THATConference session held back in August 2019, I talked through some strategies on how to accomplish this and release something every sprint, and slowly – but surely – get our apps fully converted to that new tech.

See the slides.

The Password Struggle

Thu, 21 Nov 2019 22:17:10 GMT

Today's digital world has accounts everywhere. That means logins and passwords.

But systems get hacked, hackers get our login info and our accounts get compromised. And now, we got a problem.

So some solutions then pop up.

Like Multi-Factor Authentication. So then, if someone gets a hold of your password, if you have this setup, you can stay safe. Er. Safe-er. If someone gets ahold of your "factor" (which is less likely), then you're in trouble again.

Or, the bajillion ways multiple websites require you to have various different letter, symbol, capitalized and lower-case letters to ensure a more secure password.

Or, the bajillion systems who require you to change your password every x days.

Or, the push for you to use different passwords for every single thing.

Which causes yet another issue because then, we have so many passwords, and we can't fit it all in our brain, so then we forget and we reset our passwords, and we have yet to remember another one. Which we will likely forget again anyway.

So now, we got the problem of too many passwords, so we get password management solutions to remember our passwords for us.

I mean, login with x platform makes things better and easier, but not all systems support it, and it usually also means my data is shared.

All of these solutions and problems seem to go back to one thing: passwords.

So. Is there any password-alternative out there to be able to have access to an account? There has to be some other thing? I tried a quick google and couldn't find anything.

Do you know of any alternative solutions? Please save us from this password struggle that has overrun our digital experience today! :sob:

Join us on DEV to discuss further.

What is a Team Lead? What is a Tech Lead? Are they the same or different?

Tue, 19 Nov 2019 22:03:09 GMT

To you, what defines a Team Lead? A Tech Lead? If different, is there a term that describes both roles combined?

I always get confused which is which. 🤔

Join us on DEV to discuss further.

3 Valuable Concepts Learned Early in My Dev Career

Sat, 12 Oct 2019 21:11:57 GMT

1 - Source Control

Source control is a way to capture and track changes (control) to your code (source).

Source control is essential in a professional environment. It allows developers to work with each other and ensure their changes do not conflict with each other. It also keeps track of each code change as a version and it is a must have to keep the developers' sanity with multiple environments (point #2 below).

Git is a source control system, and GitHub is an online platform that uses Git for source control.

Source control also enables branching, wherein you make a copy of your stable code (typically termed master branch) and make updates to that copy without impacting your stable code. This is an important concept because developers can then work on their own copies of the code without impacting each other's work.

2 - Environments

In addition to source control, we had multiple environments we would deploy code to. Environments are a set of servers and/or apps to which you deploy code to and run your app in.

What are the environments for? Stability.

In a professional work environment, there is usually ongoing development effort most of the time. And code changes = instability. You can't know for sure that a code change didn't break anything. (Tests are ways to increase the confidence level that nothing's broken, but that's a more advanced and larger topic and to keep things simple, I'm intentionally not expanding on that in this post.)

So in my team's case, we had 3 environments:

Development. This environment, we could always deploy to, no problems. If things get broken from our code changes, it's not a huge deal.
Demo. This environment we like to keep stable. This is where we do our testing to ensure that our code changes are ready and stable to go to production. To keep this environment stable, we only deploy changes that are already working and tested on development.
Production. This environment is what the end users of our system use. Any deployments to production would be made available to our end users. (Some exceptions apply, if feature flags are used, for example. But that's a more advanced topic and will not be covered in this post for simplicity.)

Environments work best if you have a source control system in place, because you could deploy a specific version to an environment.

For example:

Development has version c.
Demo has version b.
Production has version a.

So, when we know for sure that version b is ready and stable, we then deploy that version to Production, making the environments have the versions as follows:

Development has version c.
Demo has version b.
Production has version b.

So far, the environments I've listed are all remote servers.

But there is also your local environment. This environment is unique, because it is isolated to only your computer. You change the code, and "deploy" it to your local file system.

It won't be isolated any more though once you push your code changes to the remote repo (i.e. GitHub), and then get those changes merged to master. The changes in master are then deployed to Development.

So now, the environments would have the following versions:

Development has version d (your changes).
Demo has version b.
Production has version b.

We could then move version d over to Demo as soon as we are sure that its quality is acceptable.

As mentioned above, the main purpose for having multiple environments is for stability. This is done by segregating each environment from the other. Doing this ensures stability, but it also comes with a cost - extra overhead, additional costs, and environment management.

3 - Collaboration

In a professional environment, work is larger in scale compared to when you're working on personal projects, wherein you are the only developer. This means that there are at least 2 developers working to complete the work.

The code you work on in a professional environment is also usually larger than a personal project. This then requires domain knowledge to know the ins and outs of how that system works and all its various functionalities.

Collaboration, then, becomes really important because in order to make changes to the project, you'd:

Have to work with another developer to make sure the changes you're making does not impact his/her changes, and vice versa. This would require consistent communication lines between both of you, and can even require testing your changes together should you touch the same piece of functionality.
Have to work with the developer with the domain knowledge to understand the ins and outs of the system related to the changes you need to make.
Have to work with a senior developer, if available, to understand how to implement the changes you need to make. Sometimes, the work is too complex for a less experienced dev, that it requires a senior developer to design the solution, and provide simple and easy to understand chunks to less experienced developers.

The ability to be able to work with people well is a crucial skill to have in any career, no matter what level you are at, experienced or not. We all have to work with people, and if you are able to do so exceptionally well, you'll find yourself getting promoted way faster than if you didn't.

Developer 1 with medium technical skills but great communication and collaboration skills will get work accomplished faster because communication flow is easy between him/her and other team members.

Developer 2 with high technical skills but low communication and collaboration skills will, on the other hand, could result in slower time to get work accomplished because misunderstandings can happen. Worse, team morale and team trust can also be impacted, and thus, impacting the entire team's productivity.

Learn These Concepts

If you're just starting out, you can learn and practice these concepts before you get your first dev job! Learning these now would improve your marketability to employers because it would take a shorter time to get you working on their codebase.

1. Source Control

There are lots of resources out there, but this free workshop covers the basics - source control basics, git basic terms, github basics, branching, and forking.

2. Environments

One way can get familiar with and practice code and version management on multiple environments is with zeit.co. Once you link up a github repo, the master branch will be setup as production while branches will be labeled as latest or staging. Staging is another term for an environment similar to demo as described above.

3. Collaboration

To improve your collaboration skills, find another dev to work with on a repo/project.

Online/virtual collaboration would give you experience on handling the defined scenarios above. Working on/contributing to an open source project could be one way you could get this done.
In-person collaboration would give you experience in reading non-verbal communication (tone and body language). See if you can find another local dev to work with through meetup groups/school. If you're in school and you have to do group work, embrace those! They are hard but they give you invaluable experience on working with various kinds of people.

Wrapping It Up

Knowing source control and environments will set you apart from other new developers.
Having collaboration skills will make you desirable in any industry.

I hope this article has helped you and I wish you all the best if you're aiming for that first dev job!

And please remember:

Learn, practice, and make mistakes.

Don't be afraid to fail.

Failures are your steps to success.