DEV Community: Barry

How to write the best code

Barry — Thu, 18 Feb 2021 23:15:13 +0000

You have a dream. Or a task. Or something epic you want to create. You devote time to it. You have a vision. You get started. But progress is slow and it never moves much.

In the software world working with new engineers here is what I have noticed:

A desire to be perfect immediately
Too much focus on speed of completing their work
Everything works the first time

The core problem is no one makes something that is perfect the first time. Even the experts dislike their first version. It's a loop of creating, testing, destroying, and making things better.

When we work together I help them break down their problem into chunks. After identifying a chunk, I ask them to write the worst version they can that works. I don't care about style, performance, and all the things that will come. I want the most basic thing that shows progress and is working.

My motto is:
It is easier to destroy than create.

If I write something awful in code most people can 'see' the problems. Yet, if we are staring at a blank screen and trying to imagine the 'ideal' way to write something it is an uphill battle with resistance and over-thinking.

So make fucking awful art. Code horribly something that works. Forget about all the beauty and style to come. Leave all your hopes and dreams of perfectionism at the door. Embrace imperfection and create garbage. From there, revise, iterate, test it out. Find what you can and make that next version. Eventually, this process will lead to something great.

Get unstuck and start

Barry — Tue, 16 Feb 2021 19:38:01 +0000

I see this happen to everyone and I want to share one technique I picked up while being a developer that I use.

I don't use this all the time. I can't work like that. But when I am #@$ stuck, feeling overwhelmed, and having something to do it is my go-to.

I picked this up at a conference in my software engineering career but it is not specific to that. That session was on productivity hacks and in it, they introduced me to the Pomodoro technique. This is a time management method developed by Francesco Cirillo in the late 1980s. What I love about it is that you don't need anything special you can get started using what you have. The simple process is documented on the Wikipedia page.

Yesterday I set aside some focused time to write and brainstorm. The idea of writing for thirty days started to invoke all kinds of fears and anxieties. What would I write about? Can I actually do this? etc. I almost quit. Well to be completely honest I almost said fine I will 'do this later' it is 'not important now' (avoidance for the win!). But, then I recalled this idea and it let me complete what I set out to do.

There is no magic to this and it cannot do your work for you. Yet, it will help you get started and focused. Sometimes that is the hardest thing and it is easier to quit, give up, do something else.

Perhaps though that is the magic - getting started. For me, once I start and momentum builds I notice my internal resistance start to fade. And from that place, you can do anything.

Small effort big impact

Barry — Thu, 21 Jan 2021 17:34:36 +0000

I love when I find these areas because they are a win-win. The project/company/software etc wins from your impact and you win because it takes a small amount of time.

Today I want to tell you how I handle documentation for a software project. What I have found is little efforts in the documentation have an outsized impact. I cannot a scenario where someone says no or rejects your pull request containing documentation updates. For large projects, internal or external the value gained is enormous. For me, this advice applies more to documentation for stuff at work rather than hobby projects. However, honestly, good docs are such a great asset to any project regardless of size everyone wins from having them. Feel free to take pieces of this knowledge and use it in your own projects.

How I approach creating great documentation:

Take care of what you do have
Enhance what you have
Reorganize into the preferred formats
Repeat

Take care of what you have

Documents typically are not on the critical path to deliver code and features. They tend to fall behind and become stale. Having no documents absolutely is the worst but having incorrect and outdated documents falls close to it. How bad can this get?

I once had almost a three-week onboarding to a job to get to a point where I could build everything locally and run their setup. It was awful I felt crappy for not being able to solve these problems and the team suffered from the time I theoretically should have been ramping up but could not. The software, technologies, frameworks, were brand new to me and I had no idea why things failed. The team was behind and onboarding me fell behind on priorities.

As a new developer even if you don't understand everything you can write excellent notes and update the existing documents. At this step, I hesitate to change anything in terms of format or documentation technologies but make your motto to bring it up to date. You have to get going anyway so why not spend a little time /effort and have it benefit you and all future team members.

Enhance what you do have

Once your documentation is up to date, next I like to look for any changes I can make to enhance what exists.

Examples:

Adding images of screens/configurations
Creating simple diagrams to document complex flows or architectures
Updating structure so it flows better
Linking to other documents you found helpful
Adding code snippets/formatting to commands
Add a troubleshooting section / do this when this error occurs

A lot of times in large corporations, documentation exists in multiple places and it can be hard to find. As someone new, you might not know where to look. Never doubt the value of adding links to alternate places to show what's next.

Re-organize

There is no one 'right' stack of documentation. I prefer and advocate for:

Concise README's
An accompanying static site (something like docusaurus)
Everything else in a wiki (like confluence etc)

At this step, I recommend surveying what is out there and figure out your ideal standard. You might not be able to change the entire organization but hopefully, with good ideas, you can convince the powers that be for this project can we shift things around. What I love about the static sites is they are easy to set up and usually come with a decent theme to get started. You are not proposing days of work but minimal effort maybe an hour or two.

At this stage, it is important to note you need to figure out what goes where? Is your README too bloated? Should some data move from the wiki to the static site? Every option has pros and cons and guidelines would benefit the entire team so they stay within the new standards for your project.

How I choose to define these documents:

README

High-level overview of repository/purpose
Up to date instructions on how to build and run
Link to static documentation

Static Site

All the good things for a developer to know to run locally that don't fit in build instructions.

Examples

DB setup guides
How to point to other environments
Gotchas
Where to find app secrets (don't store in the document)
Testing setup and running locally
How to test manually locally and test users if necessary
Known issues
Troubleshooting ideas for local
Links to wiki

Wiki

This should have the high-level project and system architecture documents. I expect lots of diagrams/flows related to how various repositories interact. Cloud/networking diagrams. Everything that is important but perhaps too broad to fit alongside a single code repository. Project history, project structure, team members, org chart of project leadership/team members for new joiners.

Avoid this and achieve your dev goals in 2021

Barry — Mon, 04 Jan 2021 23:11:17 +0000

It's that time of the year when you see a lot of public commitments to 'goals'. I think one cool thing is more and more material is made about this as time goes on. Every year someone seems to have new ideas or thoughts that build upon previous works. To me, this proves there is no one right way and you need to figure out what works for you. It may be a combination of a bunch of stuff.

I've done a lot of different variations on goals and I still change them up. I can't fully leave goals but sometimes I kind of hate them. I do agree habits and systems are critical. On the other hand, having no goals for me feels too strange.

It is also ironic to me some goals might not get you what you wanted. There is this quote that gets attributed to various authors:

When you get to the top of the ladder you may find it is propped against the wrong wall.

I had that and continue to have that feeling a lot. It is hard to pinpoint one 'why' perhaps you go for something because it's more of what others wanted for you rather than you. Or maybe truly you thought doing 'x' would get you to where you wanted to be but it turns out that is not it. Even if you find yourself in this position you gained some experience and wisdom and can shift your course.

Similar to software development personally I like to work inside the idea of releases. It is up to you how long to define a release there is a popular book the 90 day year by Todd Herman but for me, it feels too long. Perhaps for you, it is just right. It is trial and error until you find what you want.

Whatever way you go about this I think these three ideas are critical to however you define success:

1) Be kind to yourself.
2) Less is more.
3) Don't fear change.

Be your best coach, friend, mentor you can be to yourself. Fuck the negative self-talk it does no good. Pretend you are talking to a dear friend or child struggling and how would you deal with that scenario? If you fail learn from it and get back up and try again. No need to beat yourself up for failing. Ambition and dreams are awesome but in my opinion, less is more in terms of the number of 'things' your working on. You could probably do better chasing 5 things over a shorter cycle than attempting 100 goals. Finally, don't be stubborn if something is not working or if you realize you no longer want to pursue your goal. Just because you wrote something down or invested time/money in some way if it is not working change it up. Don't hold on just because.

If you only remember one thing to take away remember this and avoid it:

The only way you really fail is if you quit.

Failure is not the end, bad results are not the end, keep going and getting yourself off the ground. You can do whatever it is you desire.

Documentation Preferences

Barry — Thu, 17 Dec 2020 20:36:04 +0000

I feel like it is great if repository has a README. However, others have shown that sometimes Markdown is not the best documentation format. What else do you use? What is your favorite documentation? What makes it great?

My favorite strategy to learn and achieve anything you want in your development career

Barry — Fri, 11 Dec 2020 22:02:24 +0000

Spoiler: I don't think there are 'secrets'. All of this stuff is out there and has been said before. Perhaps not always in the realm of coding/engineering but for our purposes, I bucket this under great strategies to learn to help you better understand how to learn. People generally want the least amount of work, the fastest route to success but usually, those stories (of overnight success) or tips/techniques(of how they doubled their income in 4 days etc) ignore all the time and action preceding these moments.

Technology, programming, or learning to code is an enormous set of mountains to climb. It is overwhelming. This strategy won't guarantee success but it will provide massive results that over time you can work with to steer more towards success (whatever that means for you)

One repeated pattern that I have noticed this week inspired me to write this post.

Here are two interactions I had:

Laurie

@laurieontech

Small improvements in repeatable processes have outsized effects.

20:08 PM - 08 Dec 2020

2 48

Barry

@_bkern

@laurieontech 🔥 I really think this is one of those 'secrets' that is not a secret but people ignore or look over because it is not as appetizing as some quick fixes or a weird quick trick to solve all your problems immediately.

20:39 PM - 08 Dec 2020

0 1

Ali Spittel 🐞 @ reinvent

@aspittel

I've read 50 books this year, and I've gotten a lot of questions on how.

1. I just love books, and that definitely makes this easier and more enjoyable.
2. I love audiobooks. I listen to them sped up to whatever pace I can listen comfortably. Usually 2-2.5x.

21:01 PM - 07 Dec 2020

9 199

Barry

@_bkern

@ASpittel ♥️ everything you said - one thing that has surprised me is that it's crazy what 5-10 pages per day can do (in terms of books per year). Obviously a silly metric but regardless I think more reading is always a bonus. Shout out to consistent small steps adding up.

21:57 PM - 07 Dec 2020

0 2

They both focus on the same thing. My concrete example is the number of books I have read. Again, a worthless metric all on its own but it helps prove what is possible by a little action. 2019 I read less than ten books. 2020 so far I have read almost forty. What is the difference? Have I been taking days or weekends to focus entirely on reading? Nope. Honestly, all I did was commit to reading 10 pages a day. Sometimes more, sometimes less. But again, consistent small action produces massive results.

With learning to code, becoming an expert in 'x', building something you want to, all these things take a lot of time and this may be a strategy you could utilize to help you on your way. Is it the only thing you need to do to become successful? Perhaps, but probably not. You can produce massive results but pick the wrong thing to work on. Or maybe what your after is a bigger puzzle and this one thing on its own provides assistance but it needs more than that.

Some examples:

Reading
You read 5-10 pages a day it adds up a lot. If you only want to generally read more this 100% works. But to bring this back to coding and development - If you only want to read every blog/tutorial/book/ on React but never work on the examples or your own projects will you know React? Eh, kind of but so much of learning a new framework/language is a solid mix of understanding/comprehending React but then doing it on your own. You need to experiment and try things and run into your own issues to really embrace what you have read and work that side of this equation.

Boosting test coverage
This just came up at work. Happens with both greenfield and mature products unless you strictly break the build for some percent of code coverage. But for many reasons I have seen it relaxed and later re-visited with conversations about why this percentage is so low. You have two options and both work. You can sidetrack the team or a portion of the team and boost this coverage. Similar to working on the 'right' thing you might get some garbage tests here solely to boost test coverage but on the flip side sure in a utopian world you could potentially get only great tests. The other option is basically this principle at work. Choose a tiny increment you commit to adding that sprint(say a couple percentage points) and devote a little bit of time over a long period and watch that number rise dramatically.

Working out
This gets complex. Here is a personal example. In 2019 I was really proud of the number of times per month/and the total number of visits I made to the gym. I set many personal records for different lifts and yes I was stronger. However, my larger goal was to lose weight and be healthy. I was definitely healthier but I didn't pay a lot of attention to my diet and honestly, I stayed within the same weight +/- roughly 5-10 pounds that whole year. This is one of those more complex areas where yes going to the gym is awesome and I am still happy with those metrics however strength/cardio is just one portion of how to be healthy and lose weight.

Coding, learning, and your career are more like working out. One thing probably isn't enough and it is complex. You can get lost just trying to learn what you need to do. An important component of getting anything you want is taking action. Even figuring that out you can get stuck. Do I work nights and weekends? Do I pull all-nighters? Do I read all the books first? Should I sign up for someone's course? There are a million ways to do it but I think this strategy is a little less obvious. It is not as quick or fast as some other ways but it is easy to commit to. And pretty soon these small consistent efforts provide a huge boost.

Doing is better than thinking and strategizing when it comes to anything tech/programming and your learning journey.

Here are my rules for doing:

Pick something to do
Commit to some amount of time you can do daily or say weekdays and go for it. Test out various times during the day to see if you complete this task better at a certain time for you.
Ensure its focused (if you want to learn React stick in React and its ecosystem)
Ensure whatever you do mixes up consuming information (reading/tutorials etc) and producing (build some stuff /try it out) 4b. If you are following some tutorial or example exactly. Then, once you do that successfully try to add-on to it or modify it in some way

Make a decision and pick something and try this out. Whatever results you get check-in in a month and figure out if you are moving more towards your goals and visions or not. Again, this is only a piece of the puzzle but it does consistently surprise me so I wanted to share.

If you do want to read further on this topic I recommend Darren Hardy's book: The compound effect.

If you liked this article, check out:

What do you think? Let me know on Twitter and follow me there for more development, programming, and general software engineering content.

WTF really is full-stack? Breaking down confusion on software roles and job descriptions

Barry — Fri, 04 Dec 2020 15:18:31 +0000

Software job descriptions and roles are filled with a bunch of noise. They span front-end technologies and frameworks, back-end technologies and frameworks, sometimes they mention types or styles of programming, sometimes they mention certain tooling related to something specific, and they sprinkle in some cloud terminology for fun. Am I qualified? Do I need to know web development to get a job? What is full-stack? It is very confusing.

While I don't think we will see all this confusion go away, I want to provide you with my view of the world based on my experiences. I think seeing through my perspective can help you better categorize potential roles and what they might be about. Additionally, for those that really do not know what is out there, I hope this helps you choose where you may want to start.

What makes this complex is these things change based on industry, level, company size, amongst other things. The smaller a company you join the more responsibilities and roles you might have. If you join a very large corporation you might be more focused on a smaller set of responsibilities. Every piece of software is unique but I think that a lot of them share common characteristics and roles you might find.

At the highest level I break down software development into three buckets:

Related to development

Roles that you interact with as an engineer, may not start out as (but could), and you could always transition to

project management and BA's
QA/QE/SDET
UX/XD
Designer

Specializations

Mostly programming but involves other things depending on specialization.

Security
Devops
Mobile
Systems Programming
Data Engineering
Data Science
Proprietary Software
Games

The rest of the programming that is not 100% the other two

Full-time programming that doesn't fit any of the specializations. Still tons of fun and awesome

Front-End
Back-End
Full-Stack

Does this cover everything? No, for sure I missed things. The strangest part is honestly it's hard to box in anyone one person/role. Most likely, you could find yourself doing a little of many of these while focusing primarily on one area. That is totally normal for me. Check out this abstract piece of art:

Similar to this but thinking of your role or career as a blank canvas - I doubt your canvas will be solidly one color. Could it? yea. But my opinion is most people do a mix of a lot of things or move around during their career. Your canvas might end up more like this piece of art? There are a million variations and they are all great. No one way is better for your career.

I break all these down below to help inform you. The point isn't to divide us or say X is greater than Y. I am creating this so you can better understand what's out there. Selfishly, I wish I had this when I started. I had no idea about the programming world and no one to explain it to me.

Roles on a team that are not what I think of as junior/starting engineering but you could transition to if they interest you:

Some form of project management/business analysts:

You will not program here
You often encounter lots of mention of Agile, Scrum, PMP, etc. All software management related.
I highlight this because the best people in this role understand software and I have seen people successfully transition to these roles if they decide that is their passion.
If you can straddle the technical/business gap you provide a lot of value. You can explain technical concepts and ideas and sell them to the business. You can also take what the business wants and communicate effectively with the engineering team to get these changes planned and implemented.

Quality Assurance / Quality Engineering / Software Developer in Test

You definitely will program here however not all the time
You will be focused on testing
This may sound boring but there are a lot of engineering problems in this layer and interesting things to work on
You must love quality and details etc.
Communication and attention to detail are very important in this role.
You must understand software and its components well.
I have seen some people recommend this as a way to get in the door and transition to full-time software engineering (My thought here is I don't know and wherever you think you are going to start be direct and ask about a move like this)
I have seen entry-level/junior jobs as a developer in test so I misspoke
I have also seen software engineers transition to this and be very successful

User Experience / interaction design

Not much if any programming here
Most of what they produce is wireframes or mock-ups that demonstrate flows/interactions
A lot of focus on the user and how they interact with the software.
There is specific training for these types of individuals and if you only know engineering it might take some work to retrain for this area.
These roles are vital to ensure what your building is going to work for the clients/consumers.
As an engineer /power user of most tooling you forget how people interact with your site and what might be confusing

Designer

Sometimes gets grouped with UX
Similar? skillset but focused more on the look and feel of the site
Produces static assets for sites/software in the proper format
Strong background in graphic design
Strong CSS skills and can publish style guides or work on styling for the site
Sometimes programming in front-end technologies but usually programming is not their main task.

Specializations

Security

Strong programming skills
Strong computer/software security skills
Strong knowledge of Linux / DevOps
This role varies wildly because there are so many things it could mean
Some roles only do audits, some work specifically administering certain tools, some do penetration testing, others focus solely on say identity and access management.
this area is extremely large and hard to summarize

DevOps

This is another umbrella term that can mean a million things
Some programming is typically involved in the glue code that customizes existing products
Strong knowledge of Linux helps
Containers/ VMs/ and friends
Kubernetes might pop up
Knowledge of one or more cloud providers (Azure/Aws/GCP top 3)
You might work more in system programming rather than web programming
Ultimately idea is using code/templates to automate infrastructure
Strong troubleshooting skills needed

Mobile

I separated this because I see it as a specialty. You can obviously 'share' code in certain frameworks and perhaps write everything in javascript (flutter or react-native or who knows)
However I always see a need an area for native mobile development
This is all external observation but I see some people who only do ios/swift and some who only do android however I also see a lot of people that love mobile and go between the two

Systems Programming

Entire focus on programming related to systems ugh my definition sucks here is Wikipedia

System programming (or systems programming) is the activity of programming system software. The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software which provides services to the user (e.g. word processor), whereas systems programming aims to produce software which provides services to the computer hardware (e.g. disk defragmenter). It requires a greater degree of hardware awareness.
languages (c and its variants, go, rust, I'm sure others)

Data Engineering

This is an umbrella term as well but I see a whole group of programmers that are focused on moving data/ consuming data/ analyzing data that is separate from everything else.
General DB knowledge is good but typically a lot of different frameworks and tools used based on needs
Some of this is done and could be in proprietary software like data visualization software (this is an entire career field)
Some of this could be all in Hadoop / Spark looking to move data around

Data Science

Another umbrella term. Tons of hype and buzz wordiness so be careful but there is a lot of opportunities here
AI/ML live here
specialized knowledge necessary
a lot of training options and from what I see even degree programs
Definitely programming but focused on this world

Proprietary Software

This is an umbrella term to represent tooling and software that one could spend a lifetime administering and doing some type of programming
Mainly Salesforce comes to mind but I know others exist
Very specialized in that you need inherent knowledge about the software and how it works to use it/customize it/ extend it
Lots of certifications available here to help you learn

Games

Lots of math
very specialized
some roles overlap in this world like UX/designers/project managers/QA
Unity, Unreal fit in here.

The rest of the programming that is not 100% the other two

Front-End

I like to define the Front-End as everything from the API layer upwards
Most likely Javascript or some flavor of language that ultimately produces JS
Other technologies exist thought for what it is worth
The front end technologies and frameworks seem to evolve at a faster pace than the back-end so a lot of constant learning
Usually I see this role share responsibilities from other areas (design/UX/QA) and it just depends on the role

Back-End

I like to define this as everything from the API on down
Tons of language options, frameworks, it really depends on the place you end up and what their 'stack' is
Usually I see this role share responsibilities from other areas (DevOps/QA/Front-End) again it all depends
Produce services / APIs/contracts for consumers
There is a lot of interesting software that lurks in this area that doesn't provide services to the web but perhaps deals with moving data around or keeping things in synch.
Interacts with data layers / involved with potentially many persistence/caching technologies

Full-Stack

This term is ambiguous and everyone defines it differently. Its not my favorite term because of this and if you see a use that confuses or if someone asks you if you are full-stack or you see it used in a description my best advice is to ask for clarity.
I think of it as someone that does work in both the back end and front end
These could be separate languages/ the same languages/ etc
You could use a framework that assists in doing it all in one and maybe that to whoever is full-stack
It's quite hard these days to know everything well - I have no doubts you could for your particular solution but I think that's why there are specializations these days.
Ultimately, find what you like - if you like doing front end and back end work that's awesome and find roles that let you do both
Some places will have separate teams for these two and you won't be able to concurrently do both. Some places will let you.

One last thing. You don't need to pick exactly one 'thing'. In fact, I think saying you will only do 'x' without trying at least some other stuff is hazardous very early in your career. Even if you do pick an 'x' remember you learned 'x' and you can learn z,y,q, etc. You are never stuck and can always work on moving around. It might take some work and you might have to ramp up on other things or change employers to find something different but that is ok! All of these areas are fun, 'good', and could be a career. It's most important you are happy with your work.

If you liked this article, check out:

What do you think? Do you still have any confusion? Let me know on Twitter and follow me there for more development, programming, and general software engineering content.

How to be one of the best junior developers

Barry — Wed, 18 Nov 2020 15:51:18 +0000

I don't care what programming language interests you, what front-end framework you are using, whether you think you need monoliths of micro-services, or if you went to a Bootcamp versus self-taught. None of that matters wherever you are starting in your development journey, because this is a lesson that applies to all developers. With everything going on its obvious everyone would agree the world is divided. Unfortunately, this divide exists in the software and development communities too.

Here is my ask for all new developers:

There is room for everything and everyone. We can all be kind, respectful, and patient with each other. I am all for encouraging healthy debate but people love to go overboard.

When you communicate with others I slice it into two buckets: internal communications and interactions and external communications and interactions.

Ultimately, what you do and how you communicate in the internal definitely carries over into the external. However, I want to highlight some different things for both. Here are my top 3 pieces of advice for you personally in your internal interactions as a new developer along with my top 3 pieces of advice for you when you interact outside your workplace within whatever developer communities you are in.

Three tips for how you interact in your personal world

Do not judge

This can be taken a million ways. Perhaps you are judging your initial team members and thinking well so and so can't be good look at them. They are so old - no way they know what is modern. Maybe you judge their education and or credentials? Maybe your first project's tech stack sucks and you think there is nothing to learn. Again, so much to bite into but a few tidbits:

Fuck what anything looks like, this is just human and stupid.
Age, gender, sexuality, race, religion, all this stuff does not matter one bit. Diversity makes us stronger and everyone can contribute. The stranger the cast of characters on the team the better in my opinion. No matter who you work with you can learn so much from them.
A lot of fields are being 'disrupted' in terms of education and 'credentials' but some of the most intelligent engineers I have worked with have had the least amount of education. I continue to learn from people at all levels all the time. The notion you can only learn from more senior people is false.
No matter how much in your own judgment system you think something sucks(like your first role or project) I promise there is lots to learn. Nothing lasts forever and eventually, things will change. It's good to develop preferences and know what you like but immediately saying this sucks is not going to help.

Do not compare

Similar to judgment but I want to call out specifically one thing. People and developer communities love to talk about engineers who are rockstars, ninjas, geniuses, etc. I think this is all bullshit. It puts you in a perspective to focus on you versus others. No high functioning team is comprised of all people like this and that is not what you want. Do there exist certain people that can produce at a higher level - yes. But does your team's success depend on having these people? No, not at all. We all have strengths and weaknesses and honestly, the only person you should compare yourself with is you. Strive to get better than you were and improve year over year.

Be kind, loving, and supportive

To invert this one - don't be the asshole. Don't be rude, arrogant, all-knowing. Confidence is fine but please give everyone a chance. Maybe you are better at something than someone else but take the time to teach/help them and you will be surprised how it improves your knowledge too. Teams are about collaboration and only you succeeding while others fail helps no one. As much as you may or may not like someone always strive to be someone they would choose to work with again. Thinking a bit longer-term one day you will no longer be a junior developer.Think about this when you become a senior working with the next generation. They might ask silly questions or be confused just like you were but be a mentor and guide to them. Help them become better.

Three tips for how when you interact with the external world

Don't be the asshole

Similar to how you act inside your company do the same elsewhere. Don't be rude/condescending on social media/ message boards. Don't jump on some hate or spread it. Be gracious, kind, and grateful in your interactions.

Embrace the variety

This happens way too much. People jump on some train about technology 'x' and if there is a competing technology 'y' well then it must suck. They write shitty things online why 'y' sucks or why use 'y' when there is 'x'. Sometimes, sadly, it's inter-community rather than across communities. They go after people on Twitter for the same shit. Or they think everyone has google sized large enterprise problems and crap on all these perfectly legitimate solutions for issues. They think their community is 'the' answer to something and go after all the other communities for doing things the way that community does. It always comes down to context but in reality, you can solve every problem in many ways using multiple different languages or technologies. Might the proposed solution/framework not be your favorite? Yep. But should you go trash some people or community just because of that? No.!! There are a million ways to do it - you choose what makes sense for you and let everyone do their thing. We are stronger because of this.

Be patient

I see this a lot with newer developers. They have an issue with something and they can't get help internally for whatever reason. They see the libraries they are using are open-source or have a presence on the web and they end up on the message boards or stack overflow. They start posting and get upset when they don't get immediate answers. Someone might ask you to refine your question or for more information. Provide it! Don't just ask for quick solutions or fixes seek to understand what is going on. These days most open source libraries have at least one way of finding their community whether it be on a message board, e-mail list, chat room, etc. Definitely use all these resources but have patience. The authors/contributors might be very busy and it can take some time to get answers and that's ok. Search everywhere you can and attempt your hardest to find the answers.

In closing, there are so many interesting and exciting developments being made in all areas of computing/programming etc. Find what you love and go be the best community member you can. Help advocate for it, answer questions, contribute. Maybe your time has come and you decide to move on or explore other interests. That is fine too. Go try something else. There is room for everything and everyone honestly. We can all be kind, respectful, and patient with each other.

If you liked this article, check out:

My #1 tip for new developers

What do you think? Let me know on Twitter and follow me there for more development, programming, and general software engineering content.

My #1 tip for developers starting out

Barry — Thu, 12 Nov 2020 20:14:56 +0000

Do you know what the most common internal development team failure is?

Communication issues

As a junior or brand new team member you will never be responsible for the team or its problems. However, you definitely can impact this disproportionately. My best advice is......

DO NOT BE THE SOURCE OF COMMUNICATION ISSUES. RAISE YOUR HAND. ASK FOR HELP.

If you can internalize this and constantly remind your self of it - I guarantee you will be so much more successful in your development career. It seems so simple and non-technical but it is absolutely crucial. I have observed people struggle in teams, organizations, and their careers not because of their technical skills but because of their communication skills.

Now I get for a lot of reasons it can be embarrassing or shame invoking to raise your hand and stop something saying: 'Hey! I don't get it.' However:

We all suffer more the further your understanding drifts from the existing teams.

It's similar to that saying of "Shifting software quality to the left". More information on that here. The basic idea is that: stopping bugs sooner is better and costs less. With misunderstandings we can say the same exact thing.

The sooner we stomp out misunderstandings the better everyone is.

That voice in your head is not your friend here. It's probably telling you awful things, telling you that you are stupid, dumb, calling you all kinds of names, how can you not get this? , why can't you solve this easy bug, why don't you understand feature: XYZ-4032 !?!? But guess what it's lying to you. Ignore it. Ask away and ensure you get to understand why. Once you think you get it then try to explain it back to the person that just explained it.

Everyone wastes time and spins their wheels. Over the most ridiculous and tedious stuff. Repeatedly. For sure I have lost hours to missing semi-colons, typos, and all sorts of other silly things. Failure and frustration are expected in this line of work there is no way around it. You learn from this stuff and gain knowledge and experience.

When you are starting out figuring out when to ask for help is very difficult.

Do you ask immediately?

Then you run the risk of burning people out with all your questions.

Do you try to cover up whatever is going on and give vague progress updates saying things are going well but really your fucking stuck and have no clue what to do?

As much as it might suck to admit you can't currently do something or need help it is way worse for the team to not be honest and seek help when needed.

Ultimately your goal should be to end up somewhere between asking everything immediately & waiting way too long.

I struggled with this early on and still do on occasion. I can vividly recall a really early performance review where I got dinged for asking too many questions and not trying to answer anything myself. I have also been guilty of not asking for help soon enough. Everyone struggles with these things. But, no one really gave me much advice on this or told me hey this is common and you are not unique - everyone struggles.

Here is my rule:

Set a timer for thirty minutes. Try different ideas. Take notes on what you did with the various approaches. Try some googling on the error message or digging in some wikis in your internal sites somewhere. Give it your best shot and if the timer goes off at thirty minutes - reassess where you are. If you think you are close reset the timer for thirty additional minutes. If you are still totally lost immediately reach out to your architect/team lead/fellow team members whoever can help. If you get to the end of the hour and any confusion or uncertainty reach out and discuss where you are at and check your assumptions and charted path.

These rules vary based on experience and the task at hand but my max absolute ceiling is half a day. If you have spent half a day spinning your wheels or not making the progress you should be then reach out, ensure the lead knows your status and that you are stuck, and get help.

As someone about to provide help - I would love to know:

What have you tried coding wise?
Where are you currently stuck?
Specific things you looked at to attempt to solve the problem

This allows me to tailor my feedback. I can then bridge any gaps in your knowledge or understanding of our software, product, etc. I can also offer any guidance on your methodology for solving issues on the project.

Coding and development are hard. First, there are all these technical things you need to learn to be able to get a job in the field. However, once you have landed that position you face another hurdle. You have to learn how to appropriately code within in a team, how to be a good project/team member, and how everything works (beyond the code).

Good managers and team leads know you will potentially need extra help to get going. Especially if you are at the start of your career or perhaps you are brand new to a project. But at the same time, an opposite issue exists for the lead in that they want to give you space. No one likes to be micro-managed. And finding the right balance for each team member takes time especially with juniors.

The worst six communication mistakes you should avoid:

1) Hiding your issues via false progress reports that things are going well.
2) Not communicating you need help on your task(s).
3) Wasting more than half a day being stuck.
4) Hiding the fact that you don't understand something.
5) Asking for help immediately every time all the time when something doesn't work.
6) Not understanding the solution to your problem when someone helps you.

If you liked this article, check out:

How to be one of the best junior developers

What do you think? Let me know on Twitter and follow me there for more development, programming, and general software engineering content.

Effectively avoiding pitfalls when scaling an engineering team

Barry — Mon, 09 Nov 2020 16:26:41 +0000

My favorite type of development is greenfield. Everything is brand new and you get a blank slate to work with. You get to choose the languages at use, which persistence technologies you will choose, which frameworks you will utilize. You define the architecture, select the appropriate hosting or cloud provider, and implement the initial code exactly how you want. It can be wrong or off but it is so early refactoring here is typically not a bad idea.

My favorite type of project keeps things small. A development team of five or less and the right supporting staff to help run the project. Every new team needs time to cycle through the various phases until your working smoothly but with a small team I believe it happens much faster. You can keep processes lean and overhead small. Things seem to just happen and you can iterate quickly.

This type of team or project could happen anywhere. Whether it be a couple of friends, a new project at work, or someone's startup. Because the size is small information flows freely, a consensus is easy to reach, and blockers can quickly be dealt with. Delegation and individual responsibility are also key here because the development team is small. Every team member gets to own a significant chunk of the overall work. Work gets completed quickly and the project rolls on as an effective and efficient team.

Teams and or projects can potentially stay in this mode forever which is great. However, when they don't and they opt towards growth you will encounter crossroads.

Being an engineering lead or architect you are well versed in the technical aspects of growth or scale. Tradeoffs must be discussed and appropriate changes took (at the appropriate time) to handle scale and load. Ideally, you plan for a stack that can handle your initial ideas but forgo premature optimization until you reach that need. These decisions and tradeoffs can be difficult because the information is not always clear and there is no right answer. Some proposals could be little changes for big wins while others look daunting.

On the other hand, perhaps the initial architecture choices are sound but need some gentle shifts to enable new features efficiently. It's not always a lot of traffic that is the technical challenge. However, with any technical challenges experience definitely helps guide your intuition. Your focus and perspective are on engineering and technology and you analyze and adapt to problems.

Maybe to get these new features out faster than your existing team could you raise money or you somehow augment your team to theoretically do more faster. This is a contentious point but I am avoiding it for now. No one project is the same but in my vast experience I have always had a team grow in waves rather than a big bang and 15 developers show up the next day.

Sooner or later when growth occurs you start arriving at crossroads in the non-technical areas of the project. These may or may not be in your control but awareness is key here when you do not have the responsibility yourself to make these changes. With awareness and some way to influence or make these decisions, you can then look for solutions and propose them to help the team through these turning points.

The funny thing is with these blindspots is that it's all a metaphor and they don't always stick out to you like an error in your logs or your application breaking when you submit a form. For sure if your team is now super dysfunctional you will feel it faster but if you are slightly going off the tracks or slowly picking up bad habits it's harder to see this.

Your perspective, awareness, and the way you work need to scale along with the team.

If you attempt to keep doing what you are currently doing sooner or later you are going to fall into these traps or crash into what you cannot see.

It is impossible to be very specific and say watch for this or that because every team and project is different. However, what I have noticed is that as your team grows you reach a point where you will need to change to support the larger size.

What was implied must become concrete
What was general assumptions must be documented
Informal processes will benefit from being more formal and documented for others to follow.
Where perhaps you had loose and anything goes ways of working needs to shift to being more structured and documented so they can be repeatable
More people in a meeting at some point is ineffective and you will need to start focusing the audience
As a leader you need to delegate and dictate appropriately
Favor consistency and repeatable processes
Not all decisions can be or should be entire team decisions
Extra effort needs to be made on distributing communication consistently so everyone is on the same page

One concrete example I can think of:

Never have I ever been on a team that scaled that didn't encounter issues with how to approve pull requests. When you are small it is weird to lock a pr to 'x' number of reviews. I don't advocate cowboy coding or pushing straight to the main branch but once you have greater than one developer you all collaborate and review pull requests. Things magically get done and work in a small team. Eventually, you get bigger and perhaps you say fine 1 person has to review and the process becomes a little more official. This usually works well for some time but then you get bigger and concerned people might not get patterns and maybe someday it becomes two. The other odd thing is figuring out who needs to look at these. Is it something you post in a chat channel and ask for? Do you use your tool to assign reviewers? Do you maintain a list of who is an appropriate reviewer ? by tool or technology? How do you keep that updated? What if assigning reviewers doesn't automatically inform people they need to do something? How long is too long to wait for inaction on a review?

All these things have popped up for me and the challenge here is there are a lot of ways to do this but you need to pick one and own it. Change if it doesn't work. Don't let individual teams do things differently. You want and need consistency. It is crazy to me how much time you can waste here when you all are engineers and know a general way pull requests get approved and merged but ask enough people and everyone feels differently.

As fun as the early, anything goes, we all own a lot phase is eventually it only works well for teams of a certain size. After you grow beyond this it's important to be aware of it and start shifting to a different style. Otherwise, your team suffers from an inefficient operating structure and you start negatively impacting your team members and their happiness.

If you liked this article, check out:

How to suck as an engineering manager

What do you think? Let me know on Twitter and follow me there for more development, programming, and general software engineering content.

Programming languages and death

Barry — Wed, 28 Oct 2020 00:00:00 +0000

I recently came across a blog post about trends and the top 5 languages that are 'dying'. The author hypothesized that you should avoid these languages at all costs and provided some evidence of why they think so. This topic is ripe with things to dig into but since its almost Halloween I want to focus on death.

Death is very black and white. You die and you no longer exist (physically for sure). There is no coming back. A lot of pain and suffering follows for everyone involved who remains. It is unfortunately something we all get to deal with one day. Programming languages don't really die. Some stop being used or become less popular but nothing is stopping you from using said language and its tooling. If it has been enough years perhaps it is not ready for modern development or for your machine but if you have enough energy and time you can resurrect a programming language from 'death'.

The whole problem with death and programming languages is its all opinions. You have to trust where and how these numbers are gathered to even start to moderately feel comfortable with the assumptions being made from said data. These dying languages came from compounding a few sources of data that could be reliable but I think they do not tell the full story. I use three of these dead languages all the time ;)

Here is the other side of the coin that I think is powerful. Even if a language is dying or becoming less popular a lot of value can be gained from it. Why did it get invented? Who invented it? Where does it chart in relation to features/paradigms in other languages? What can you learn from it? All these things are worth learning no matter what.

Back to death again - here is the funny thing with programming languages and frameworks. If it was popular enough even after
the buzz settles down - it's going to be in use for a long time. Perhaps it was used to build businesses? Or perhaps a company went all-in on it? Older things that work sometimes just get left alone or deprioritized in the corporate world and remain. Look at all the COBOL in banking. When did that language 'die'? I am currently supporting an API that uses SOAP for web services. When I google SOAP Google says it died on 10 July 2009. This is all too common in large businesses. Better things have been invented since SOAP but I think it is worthwhile to study it and understand:

why it was invented?
What problem was it attempting to solve?
Where was it successful?
Where did it fail?
Why did the masses move on from it?

How to approach any graph summarizing programming languages/frameworks:

1) Take every graph with a grain of salt and really try to understand how it came to be
2) Every dying or dead language or framework provides something to learn.
3) Dead or 'dying' languages can stick around long after the community has moved on
4) Unlike humans even dead languages get used and having knowledge of them is powerful

If you liked this article, check out:

What do you think? Let me know on Twitter and follow me there for more development, programming, and general software engineering content.

How to suck as an engineering manager

Barry — Mon, 26 Oct 2020 19:06:28 +0000

The best ten ways to fail as a team lead or engineering manager

Miss 1 on 1's
Be so busy that the only time your team sees you is at the daily standup
Fail to delegate
Never take a team pulse or have a meeting for non-business purposes just to check in on team health
Listen to your direct reports/team members but do nothing on their input
Tell the team you understand but take no action
Put up with too much bullshit / fail to insulate team or reports from garbage
Only think of you and yourself vs. the team and/or your reports
Constantly double or triple book yourself so you attend two meetings at once and can't listen and participate in either
Consistently apologize for your poor behavior / missed meetings etc but keep doing what you are doing
Fail to communicate down to team so you cut them off from larger decisions etc. Threw in a bonus :)

This role is difficult. We understand that but when you are struggling it is up to you to be aware enough you are not doing what you should be doing. Or that your too busy and seek help. Find a mentor. Not sure if you suck? Ask your team for some honest feedback outside of any formal processes.

I have noticed for management and above their reviews typically fail to incorporate feedback from all levels or the feedback is cherry-picked from certain people which abandons any hope of honest and real feedback. Want to know how to overcome all these?

Invert every one of them.

For example: Instead of missing 1 on 1s ..make them. If you know you cannot make today's or need to make changes then proactively communicate it. Proactive is not when the meeting is supposed to occur or 5 minutes before. Do better than that. Avoid:

Skipping
Scheduling and missing consistently
Rescheduling each one multiple times

Complaining and being negative is always easier than actually doing something about the issue. However, I see a lot of value in listing negative things because I think showing people what not todo is a nice way to get things going in the right direction. It is impossible though to define how to fix every issue seen above and I know with the appropriate context sometimes this shit has to occur. However, even if there is some bullshit you can be transparent and open/honest and let your people know. Acknowledgment, taking responsibility as the leader, and proper communication are key when you do have to go through less than ideal times.

Engineering management is an odd path. It is a difficult transition from architect to manager. Sometimes the only way to make it on up the career ladder is this route so people go for it when they should not. I hate when people choose this path for career reasons only or they have been forced this route. Every great architect cannot be and should not be an engineering manager. It is totally fine if you don't want to manage however in many businesses they fail to realize this and end up with bad engineering managers which unfortunately affects many more people.