Broken Intellisense :: Lawrence Gasik

Monday, April 10, 2017

Ed Wisniowski wrote a blog post on coping with the difficulties of being a scrum master. He talks about some steps that he takes to keep his professional life from taking over, working with others, and sleeping patterns. It is true that he's got a position that demands a thick skin, and people skills are essential for success.

Perhaps the most unique part of what he's talked about in our industry is the sleep. Anyone will tell you that their job is difficult because of how it can take over, or the individuals they work with. But the sleep portion is something that is quite a bit different at times. Ed's strategy involves making sure he has that uninterrupted sleep. Like Ed, I've interacted with offshore teams. I've skimped out on sleep, or tried to split it into multiple chunks. I may not get the 8 hours I need, but I can get 5 hours here, and 3 later, that counts, right? It doesn't work.

Thebenefitsofsleepcannotbeunderstated. When you're not getting quality sleep, the quality of your life suffers. You're going to get sick, your brain will not function as well, you will be cranky - you get my point. I can remember multiple times where I would show up at work exhausted and unable to solve problems. At the same time, I remember accomplishing surprising tasks in part to being well rested. The sleep also impacts how I interact with others. If I was up late working on an issue, and someone attempts to exchange a pleasant greeting- well, it may not get a great response from me.

I encourage people to get sleep. I encourage them to turn off and escape from the workplace that can be toxic when people give exceeding attention toward it. I have seen people become the "all knowing" individual of a system, and had their vacations interrupted. I've seen people depart from positions because of their schedule. Know your limits. Know where to draw a line, and be proactive in providing options to prevent this from happening. You need to be flexible, yes. But you also need to protect your own sanity.

Saturday, October 22, 2016

Recently I declined a job offer. The position had some
amazing perks including a lot of time off, picking out my own hardware I worked
on and a corner office with an amazing view of the Chicago River on both sides.
The position was being the sole developer for a non-profit organization. They
were small, and genuinely seemed like great people. It was clear to me that
they were treated well and happy being there.

During my interview, I was able to ask questions about their
development process. It was really non-existent. Things such as source control,
testing, and continuous integration just was not happening there – yet. I
viewed this as an opportunity to implement a development process. This could be
a great way to not only say that I know about continuous integration, I
implemented it. I was setting the standards. I would set the standard. They had
a number of projects there that I saw potential in and they were a chance to
use technologies I hadn’t done before. The possibilities were seemingly
endless. I had a chance to be Superman.

I put a lot of thought into the offer. I discussed it with
multiple developers, trying to see if I was missing something. I talked to
non-developers who worked in non-profit organizations for their insights. Four
years ago, I would have accepted the offer. I would have viewed it as my
opportunity to do something big.

But at this point in my career, it isn’t the right fit for
me. I didn’t realize that despite enjoying being a heads down coder, working
with others made me a better coder. I thought about how many times I’ve sent a
code review to someone and asked, “What do you think?” Often times, they would
do the same to me. Looking at other people’s code and being able to discuss it
made me think about how I can approach problems differently. I thought about
how I recently acted as a mentor to three developers and gave them wisdom and
feedback. In turn, they asked me questions that maybe I couldn’t explain
clearly right on the spot which forced me to think about how I can word things
more concisely.

Had I taken this position, there wouldn’t be anyone there to
enforce process on me. No one there is going to make sure that I have
everything checked in properly. No one there is going to make sure I’m
following my own rules. Being Superman would mean I would be responsible for
everything – even in times of disaster. What happens when I misunderstand a
requirement? What happens if I make a typo and it isn’t caught until it is in
production because there are yellow screens everywhere? Not only that, but
being such a small IT department, I would probably be called upon to fix paper
jams in printers and telling people to turn their computer off and on again
because something isn’t working! Who is going to send me pictures of dogs when
I’m overly stressed about an assignment? Who will I learn from, and who will
challenge me to be better?

I don’t want to be the smartest, or the only developer in
the office. If I’ve learned anything from where I currently work, it is that
the overhead of working with other developers is worth it to have multiple
minds on the problem. It makes for better software, and better developers.

Tuesday, September 6, 2016

Search Engine Optimization (SEO) is a marketing strategy to help your website appear higher in search engines such as Google, Bing, or Yahoo. It is important to be listed in search engines because that is how customers will find you. Being listed in the top spot makes it more likely than anyone else. How often do you look at the 42nd ranked item for your search results?

Each search engine has their own algorithm which helps put content in order. Every organization wants their web site to come up first. This creates a competitive industry where businesses will do anything they can to get one spot higher than the other. Businesses will hire people to constantly be working on improving their ranking because it is so critical to their business.

Odds are you won’t have the resources to pay someone full time to get you on the first page of Google organically. Sometimes, you can have a day or two in downtime and want to do something quick to help improve the traffic to your website. Some of the things people do to help their search engine ranking can be done quickly, and are long lasting. Here are five tips that you can quickly do to help improve your ranking.

HTTPS allows for a secure communication between your visitors and your website. This is used with any reputable bank, e-commerece site, or anyone using information that could be used in identity theft. While securing your site is not free, it does allow for a quick way to help improve your page ranking.

Update Content Regularly

As a user, would you rather have content that came from today, or content that came from 1996? By providing new content regularly, you’re showing that your site is being maintained. Things such as industry news, product sales, or a simple blog can be a great way to generate new content for your web site. Not only will these help your search engine ranking, it gives your visitors a reason to return to your site regularly. Returning visitors are more likely to be engaged in your content and trust your brand.

So write a blog post. Change up your home page a bit to feature a different product. Update your about section. Content is king. Provide fresh, relevant content regularly and you can get a great boost to where you are in a search engine.

Link

Think about how CNN or any other major news outlet is one of the top web sites when you search “news”. One of the big reasons for this is the way links can impact where you rank in search engines. When many people are linking to your web site, it is considered to be an inbound link. These help your credibility as a trusted source. Trusted sources are listed higher than non-trusted sources.

Additionally, when you link to trusted sources, it helps you as well. These are called outbound links By referencing a trusted source, it is viewed that you are using trusted references, and that your content is documented.

Links are also what help create the Internet. When search engines find new web sites, they find them through other web sites. This is how these search engines build their database of web sites. When many sites are linking to the same site, or page, the importance of that site is increased.

Remove Broken Links

Remove any broken links on your current site. Over time, websites go away, they change URLs, and so on. When you have a link that breaks, it comes across as your site is abandoned and no longer maintained. There are a lot of great tools to help make sure that your links are in working order:

Remember – the search engines you are targeting are about delivering content to their users. If you help make it easier to deliver content, they’ll help drive traffic to you in exchange.

Contact Page

Create a contact page – correctly. At the bare minimum, have your name, address and phone correctly marked up with the appropriate micro data. Take advantage of Google’s Map and Street View. By having it easy to find your location, and contact you, your page becomes easier to index. Search engines are designed to make it easier for users to find information and this type of content is considered to be valuable content.

Big search engines additionally favor local businesses over ones further away. This is why when you search for “driving range” or “dry cleaners”, local businesses are returned higher than a business a thousand miles away.

A few things to remember

Results do not happen overnight. While these are considered quick tips, they’re quick from an implementation perspective.

Everything is automated. It doesn’t matter if your page looks amazing – the content has to be easy to get to and read by a computer. No one is out there manually ranking your page higher than your competitors.

Reputation is important. Do not take short cuts. Do not try anything shady that will get you black listed from a search engine. Once you’re blacklisted, you’re done. Your business may end up closing its doors if no one can find it on google.

Monday, March 28, 2016

I’ve been working with relatively green developers the past few months. I’ve been trying to find an efficient way of letting them learn from their mistakes and be creative without damaging the integrity of the product. A lot of times, questions are asked of me that I explain as best as I can on the spot. Sometimes I do a quick search on Google and find a few articles that have been better thought out than my on-the-spot explanation. The other day, a developer asked me why circular dependencies weren’t acceptable. I explained it partway, but I couldn’t find a well thought out writing piece that explained it.

How this occurs

Suppose you have a Data Access Layer (DAL) and your own logging layer for auditing purposes. Inside your DAL, you’ve got a method that is supposed to insert a record into the database. In the event that you add a record to the database, you need to log it by calling your audit logging layer. The logging layer will accept the request, and try and log it to the database using the DAL.
Now you’ve got a problem. What if the method that was initially called in the DAL is now the one that my logging layer is calling? You’re going to go around and around in a circle.

What I saw

The project I inherited has been worked on for many years by over 100 developers of different strengths in their skill set. One area that I come across frequently is how projects are referenced. Rather than adding a reference to the project itself, developers add a reference to the DLL in the Bin. Sometimes this works, other times I would have to hit Build multiple times to get a complete build. The developer was getting around the circular dependencies problem.

This can “work” based on the build order. Visual Studio helps out as best as it can, but it cannot help out with references to DLLs directly. Projects references need to be added correctly for Visual Studio to help you.

How do you solve this problem?

The example above will never end. It violates the Single Responsibility Principle. The Single Responsibility Principle states that each object will be responsible for only one purpose. There should be only one reason to change the class. While I try not to go overboard with SOLID design, this is an example where you have two different layers that need to be called by a middleman.
Create a layer that calls the DAL directly. In this newly created layer, also call the logging. This prevents you from creating a circular dependency.

Each object now will follow the Single Responsibility Principle. The DAL only puts things into the database. The DAL does not care about logging, who is calling it, or what happens next. The Logging Layer will allow for other middlemen to call it, and it will behave the same way. It can log using the DAL if it wants, or it can call a web service, or log to the file system. Finally, the middle man is responsible for making sure that both the DAL and the logging are called. The middle man is responsible for the order of execution, but it does not care how either the DAL or logging occurs, just that it occurs. Each layer only has one reason to change.

Sunday, March 20, 2016

Ed Wisniowski wrote a post called E-mail – the Enemy of a Scrum Master. He calls e-mail a time suck of busy work, and a poor way of conveying information to others. He makes some valid points about e-mail and how it is abused. Ed and I work together, and work together well. He and I are often receiving a lot of the same e-mails and included on the same exact chains.

I’ve seen lots of different tools tried to be used, some come and go. Others stick around longer and make traction with certain teams and that’s great. But it is specific to that team and everyone has to be involved in it and learn it. It doesn’t matter if they’re using webmail, Gmail, Outlook, Thunderbird, a Mac, or a cell phone . Everyone has an e-mail– it is the first thing that people get when they go to an organization. I had an e-mail at my current company before I had a computer!

What I’ve discovered as a developer is that e-mail is my favorite collaboration tool. Screen sharing is great, but there’s always problem with people not really paying attention, having connection issues, and being there. Trello is certainly popular, but it requires people to learn to use it, discussions about how to use it, and so on. Instant messenger is great, but then there’s different networks, versions, requiring the user to be there, and so on. E-mail on the other hand – everyone knows how to use it, e-mail isn’t dependent upon any software, and it doesn’t require both parties to be available.

But perhaps the best part of e-mail is when it requires my attention – on my time. Ed can send me an e-mail asking me for a status update, notify me that he is requiring a report for an upcoming meeting, or anything else and I don’t get interrupted. Writing software is tedious and requires undivided attention to write it efficiently. I turn off e-mail notifications because I don’t want to be interrupted. I do the same with instant messages. Every interruption anyone receives, including scrum masters, delays that task from getting done. Developer or not, flow is the hardest thing to find in the work place and it should not be destroyed.

Ed quotes the agile manifesto saying that face-to-face conversation is the most efficient way of conveying information. This is somewhat true- face to face communication is the most efficient way of getting information to people. If I’m working with a developer and we are speaking, having a hard time conveying information to each other, we can walk to a white board, sit down at a machine and look at something, look at documentation, etc. This requires developers to be in the same location. This can be a problem when half of your team is on the other side of the world. It can also be difficult because one of the parties may be elsewhere physically (like in a meeting) or mentally. Additionally, if there is something that is forgotten, or not clear, another instance of communication needs to happen again. This frequently happens with problem solving. With an e-mail, the communication is there in black and white for reference to at any time in the future.

Ed gets at least 3 times the number of e-mails I do. This comes from his role on the team, and the number of teams he's on. I frequently unsubscribe from automated e-mails. I have told people to not include me in certain subjects unless necessary. I decline meeting invites if I’m not needed. I recognize Ed’s problem of e-mail abuse and deal with it as best as I can.

E-mail needs to be used efficiently. Specific subject lines, bullet points and bold text are all great ways of making your e-mail efficient. The first lines of most of my e-mails frequently indicate what I’m trying to do and the problem I am encountering. Long e-mails are frequently ignored by readers, same thing with frequent or automated e-mails.

It takes time to develop the skill of managing e-mail, and communicating efficiently in them. I find myself taking an extra minute or two with writing and reading e-mails so that I do not waste others’ time. Our job isn’t to communicate about software development, it is to develop the software. Communication just helps us write the software as a team.

Friday, March 13, 2015

I wrote a post about how there are many things I don’t like about scrum. But I do like scrum in general. There are parts that I may not like about it, but nothing is ever going to be perfect. I’ve seen a few different approaches to scrum, and it has evolved since I first started doing it seven years ago.

Scrum is a framework intended to help prioritize tasks and improve teamwork. Through communication, better estimations, and feedback, the process of completing tasks is supposed to move quicker as time goes on. Scrum is used primarily in the software development world, but I’ve had it applied in the accounting and marketing departments. There are also stories of many other projects that are not software based that have had scrum applied.

Scrum is easy to understand

Even if you’re not familiar with the scrum process, or you’re new to it, you can contribute and understand what is going on. With a little bit of training, you can understand the roles and expectations everyone involved. Take a look at a chart, the task board, or attend a stand-up and you can get a good idea of what is going on.

Break downs

By going through the planning of a story, I believe you’re actually starting your work! I’ve always been a big fan of planning. In college, I had to account for nearly every minute of my time a week in advance so I could make sure I knew what I could accomplish. When you task out a story, you’re breaking the story down. You’re making a plan, and the team can say, “You’re on the right track!”
I like seeing things organized in a way that I can categorize them. The smaller the compartment, the easier it is for me to understand and accomplish. It helps prevent me from getting overwhelmed which I have done so often in the past.

Task Boards

Physical task boards are the best! When I’ve seen the task board at its most effectiveness was when each person had their own color post-it and had to get up and physically move the post it to the done column. There is something in your mind that makes you feel good when you physically can move something. However, now I always work on a team where we need a virtual task board. On the surface, it serves the same purpose but I don’t find it as satisfying.

The task board allows anyone walking by to silently take a glance and answer the question of “What is the status?” I hate that question. The task board will tell anyone exactly where developers are at and you don’t need to interrupt.

Stand Ups

I can get caught up in my own world. I can get so focused on a story that I lose sight of what the rest of the team is working on or struggling with. When I am operating at my best, my headphones are on, and I will forget that I’m around others. This means I don’t interact with anyone. I prefer it this way.

Stand ups force me to look at people, gather around the task board and listen to everyone speak. They can ask me a question, or I can help them out if I see something going on. The best part is that it is limited to 15 minutes! Of course something can come up that isn’t stand up appropriate and we would talk right after.

Projections

I like looking at projections. I like knowing, “On February 28th, we should be done with our project. It becomes a competition for me because I want to then say, “Ok, let’s see if I can finish by the 21st.” It becomes an interesting game for me. This creates an internal challenge.

Projections also allow management to plan around the development team. I have yet to see a better way of setting up projections in software development. If the product owner wants tax calculators to be done by April 15th, set the priorities, do some averages, draw some lines and you should be done.

You even have projections in just an individual sprint. “Can I earn myself an extra day of training by finishing early? Let’s try.” Projections tell you when there are problems, or when things are going well. As long as your team is honest, and thorough with their estimations, there can be a lot of great things to be done with the projections one can generate from the scrum process.

Faster Turn around

When you can deliver part of the software, you should deliver it. You’re going to get reports of inefficiencies, or bugs in this process sooner. The sooner you get feedback, the easier it is to make adjustments. From a development standpoint, this is ideal. There is nothing more frustrating than finding out that you built features based on a misunderstanding.

Clients are also happier because they get to see their product sooner. They’re spending resources and they finally get to see what they’re spending money and time on. Compare that to waterfall, where there is a big bill and they don’t see anything for a long period of time. Usually waterfall involves a dispute at the end as well.

My favorite parts of scrum involve transparency. The organization is there for everybody to contribute to and observe. There are bunch of great things about scrum. These are just a few of my favorite things that I like to take advantage of.

Friday, February 27, 2015

I like scrum. The ability to shift direction of the product relatively quickly is valuable. I think there is a lot of merit to the idea of a product that is shipped regularly. Perhaps the biggest advantage of scrum is the early feedback. Nothing is worse than getting something, and realizing it isn’t exactly how you wanted it to be.

In the past few months I’ve spent a lot of time looking and analyzing the scrum process, gone through some formal training, talked to a couple of experts and come up with my own opinions. Some do show the weaknesses in scrum, and some may be just flat out disagreements with the scrum process.

All team members are not equal.

Scrum is built on the idea that all team members are passionate about the project, and respect each other. A cross functional team is a great idea where we can help each other out when appropriate. But that’s not always the case. The truth is I’m not a BA expert. Can I do it? Sure, but I’m significantly less efficient at those tasks than I am when I’m coding. Not everyone has experience doing QA. At my place of work, I don’t even have the tools installed on my machine for design. So there’s a role/specialization in development that says not all team members are equal, and they shouldn’t be!

Additionally, team members have different levels of dedication. A disgruntled, jaded employee is going to have a different level of dedication than the new guy looking to make an impact. Their goals at the company are different. Some want to ship software, some want to improve their skill, and some want to just collect a paycheck. The idea is to hire motivated employees, but let’s be real – you cannot keep everyone happy, motivated, and having the same goal.

Self-Organizing is great but…

Scrum is supposed to allow teams to self-organize. However, it treads a dangerous line in a lot of areas. It is our nature that when five people get together to work towards a goal, that someone acts in some sort of leadership role – even if it is an unofficial one. This is the self-organization. But that conflicts with the all team members are equal. By placing leadership on a team member, that’s no longer equality. Additionally, you tend to let people who are more aggressive and outspoken dominate the conversation, potentially not knowing about the project.

For example, I once was working on a complex engine for an application that I worked on. Three developers huddled around the whiteboard and talked about potential issues that could come about. Two of us were working together, and making good progress. The third was not. The third developer was new to the organization and didn’t have knowledge of the business rules. However, because he had the type of personality to dominate the conversation it stopped progress. He should have been asking why instead of dictating. Fresh views are great, but the personality can be a problem.

Third Parties

I always seem to work on projects that have heavy third party integration. Any time you work with a third party, you inherit their headaches times ten. You cannot do anything about them, you can only prepare for them.

For example, I had once developed a feature on an application based on insurance risks and rates. The rates would come from a third party. Before actual coding had started, the contracts were written and agreed upon. The third party told me that the service I would need to call would be available in three weeks. I had mocked up a service that I could control and develop against. Not the most efficient way of developing, but it works. Once I finished up my side of the development, I really needed to test with the third party, who was now multiple weeks late. Like any waterfall project, when one module is late, it pushes the next module to be late. This delayed the release. Eventually they finished with a completely different contract that we agreed upon. You can try to protect yourself from third parties, but I find that they always find a way to disrupt your schedule.

Bugs have no real plan

Scrum seems to be ideal for a new project that is starting from scratch. You don’t have to worry about legacy code, being pulled into other projects, or bugs. Let’s face it – every developer who isn’t Larry Gasik has bugs in their code. I have yet to see anyone implement a smooth plan allowing for when things come up. I’ve seen different approaches to handling bugs, and I don’t like any of them. Reduced capacity makes planning look bad and encourages lazy developers. Swapping stories in a sprint destroys morale and timelines.

Shared Resources

Smaller organizations allow people to wear multiple hats. This can be both beneficial and detrimental. In large organizations there are almost always too many hats. This is a major problem. Depending on the project, a scrum team may not need a full time DBA, a UX expert, a front end coder, etc. These types of resources then get shared among the organization. When this happens, you’re adding another hurdle for the development team to complete their job. This goes back to a scrum team relying upon third parties. When these things happen, your projections can change based on that third party. When that third party has their own sprint or schedule, it becomes difficult to interact with them and get things done in a timely fashion.

Scrum is great but…

It is a framework. It is not intended to be followed by the book. Modify it to be what works for your needs. I’ve never had a full time product owner. I feel like I’m going to find a unicorn before I locate a full time product owner. On a project with only three people, I’ve had to be the scrum master and developer, and when that happened, it was more successful than just complaining.

Too often I am seeing scrum being hailed as a silver bullet, and that any time scrum isn’t working for a project, it is because the process isn’t being followed. The scrum framework is built upon ideals when in reality you may not have the set up that scrum thrives in.