Tuesday, July 9, 2019

Your First Job ... Software Development!

So you got that job you wanted! You’ve been invited to join a team developing software … this is the moment you’ve been waiting for, it’s time to make a difference. So what’s your first move?

When you’ve landed that first job as a software developer, it’s important to create the foundation that will enable you to build long term value to the organization and team that you just joined. And, ultimately, to add value to the customers that will use your code – both internal and external. Yes, you were hired to come in and ‘create’, but that is not the only role you are expected to play and it is important that you develop the underlying skills and habits that build value within the team. Ultimately, setting up the conditions that will allow you to excel and become an important member of the overall team.

Below, are some things that you, as a developer, should think about and create action plans to help you settle in and create that foundation for longer term success:


  1. Continue Your Education: You need to realize that your education never stops. You may have finished a phase of your education – high school, community college or a four year degree – but that is literally just the starting point. There is no way that the languages that you have learned to this point will be the languages in use by the time you end your career. If all else fails, you will be introduced to new frameworks, development paradigms and development tools. If you are to build value as a developer, you need to identify how you will continue to learn and how you will be seen as a positive agent of change. Don’t wait for the team that just hired you to invest in your skillset and overall professional knowledge. You will need to find ways to keep abreast of the changing technology, development paradigms, tools and frameworks. This will make you more valuable to the team and open up possibilities to play other, more expansive roles in your future. Some of this, you can do on the job, but if you really want to excel as a team member, you’ll find time outside your normal workday to continue to expand your knowledge.
  2. Establishing a Mentor Relationship: If your boss has not assigned you a mentor, ask for mentor. This is important for multiple reasons. First, you want access to a resource that help you become familiar with the teams choices for tools, frameworks and other technology. Additionally, this person should help you navigate the expectations, rules and norms of the team. Last but not least, the mentor will also be available to assist you in how the company operates – what happens outside of the team that you need to be aware of and how to interact with other parts of the organization, learning the soft skills that will help you navigate your career.
  3. Understanding the Technology Stack/Tools: Back to learning! Yes, one of your first tasks as a team member is to learn the stack that your team uses to build apps, the frameworks that they have in place to accelerate the development process and the tools that they use to plan, build, test and implement the code you build. This covers everything from the editor to understanding the layout of the development environment, what authorities you need to establish to access the environments and to build your apps and your test and build tools. And, yes, as a developer, you’ll be expected to do more than just write code. Use your mentor and team members to understand the overall stack used to build apps by the team, the apps that are typically supported by the team, the integration points between the apps you’ll be working on and other applications and interfaces that the organization supports.
  4. Ask For Help: You are going to be overwhelmed! You need to stop telling yourself you’ve got this and ask questions to quickly close the knowledge gap between yourself and your teammates. Everything from what the accepted behavior is within the team – do people want unscheduled interruptions, do they prefer you schedule time with them to discuss roadblocks, how do you use the communication tools and what’s the norm – IM vs Slack vs MS Team vs eMails vs FaceToFace vs Video Conferencing, what are the standards the team follows MVC vs MVVM, syntax formatting standards, variable/object naming conventions. Right now, you are not the smartest cat in the room. Even if you scored perfect ACTs and had a 4.0 thru your collegiate career, your teammates have real world experience developing code and using the tools/frameworks and internal corporate processes that you simply have no experience with. Be humble and recognize what you can learn from others.
  5. Be Humble: Your excited, you want to contribute, you want to show your teammates that you add value. Do yourself a favor – listen, listen some more and when you feel you’re ready to speak, listen some more. Your job is to learn from the folks who’ve already cut their teeth and know the ins and outs of the applications your working on as well as the expectations of the customers and the organization. Coming in with little or no practical experience and beginning to act as if you have the solution to every problem the team is having is a fast way to alienate the very people that you need to be successful. Listen to what they have to say, ask questions, understand why they want to do things certain ways and what the history is behind decisions. After you’ve spent plenty of time understanding, then contribute your solutions being mindful of the history of how the team got to where they’re at today.


And here are the more technical issues you’ll need to think thru to establish yourself as a net contributor within the team and to make that foundation your building a rock:


  1. Security Is A Requirement: The days of being able to push out applications, api’s and frameworks without security consideration are over. Security needs to be a central consideration in the changes you are making, how you test those changes, how you implement those changes and how you support the changes in your production environment. The days where a ‘hole’ could be tolerated because nobody would really attack your organization are long gone. Highly skilled teams are actively scanning the internet and are using social engineering techniques in an attempt to infiltrate your organization and either hold it ransom or to steal the data so that they can use it to make money. Developers need to be aware of the role they plan in creating hardened applications and production environments that allow your customers to do business with you, but that put barriers in place that make it difficult for bad actors to wiggle their way past the front door. This not only includes changes in how you develop code, but ensuring you act as a good citizen by not opening emails or clicking on web site links that could be used to deliver ‘unwanted trojans’ into your environment.
  2. Your Code is Bigger Than You: These days it is rare that an application can be written that is completely stand-alone. Most applications created today are expected to interact with other internal and external applications, data repositories used for ‘big data’ analysis or artificial intelligence models. You may be tasked with working on a single function, but  you need to be inquisitive and understand how your piece works with the greater whole – within the overall application being touched – or thru feeds to other systems, api’s that utilize the data you capture and any other way that your app/data could be used. Start learning the complete data flow of the application and the data used/touched by the application.
  3. Code Reuse Is Encouraged: How things have changed! When I first started programming – yes I used a chisel and a stone – the internet did not exist. In other words, if you were creating something new, you were by and large pounding out all of that code. Sometimes you got lucky and you could reuse chunks of code that other developers had, but that was uncommon as code wasn’t really modular and you had to use sneaker net. Today, developers can hit GitHub, StackOverflow and other web sites to search for snippets of code, frameworks or libraries and to get answers to questions that they have on how to code something up. I remember the first time I was able to ask a question via the internet and someone in Australia answered my question. I was stunned – today we all take that for granted. Additionally, most organizations now have API’s that are used internally and documented in a way that makes it easy for developers to utilize. Why spend hours attempting to write something when you can call an API or obtain some free code via the internet (just pay attention to copyright).
  4. Code For Tomorrow: This really highlights multiple things that you need to be aware of. One, what we write today, makes no sense tomorrow. I can’t even begin to tell you the number of times that I’ve written code, gone back in a year later and asked myself WTF! Seriously, sometimes what looks like an elegant solution today, looks like gnarly old junk later. So, a couple of things to remember. One, you need to create your code in a way that can be easily understood and is extensible. You don’t know today what business rules will change tomorrow that will cause you to have to go in and modify or extend the functionality that you’re creating. If you’re not familiar with the term micro services, you may want to educate yourself (see that whole learning thing again) so that you can create small snippets of code that can tie together to perform business functions. These can be reused and tied together in ways not seen today that will solve tomorrows problems. Additionally, take the time to comment your code. Each team is different as to the standards they have for when to create comments, but don’t think you are above having to comment your code. Someone else is most likely going to have to touch that code in the future – maybe you – and they are going to have no idea why you were making some of the coding decisions you have made to create your code. Be nice to your future self or that developer sitting next to you.
  5. Code Reviews Are Mandatory: These are no longer optional. Unless you are a team of one – and even then, I would encourage you to find someone to act as your code reviewer. Today’s environments are complex and you have many more things to worry about that could go wrong. Security being a critical component. This isn’t just about ensuring that your coding style conforms to the standards of the team, this is about ensuring that your code is optimized to run in your production environment, that it is hardened and can’t be used as the back door into your systems, and can be used to mentor each other on coding techniques. I have seen newbs provide important feedback to veteran developers thru code reviews and this is a great opportunity for your more experienced developers to share their wisdom with the developers that will grow within your organization.
  6. Unit Tests Are Mandatory: If you’re not testing your code, go back to square one and do not collect $200. Seriously, it’s 2019, if you don’t understand how critical unit tests and integration tests are to the success of your code, then get with the program. It is going to be tough for you to add value to the team you’re on if you’re are constantly breaking things – no better way to break bonds with your team. My teams will tell you that I’m very passionate on this point, probably only 2nd to team members understanding the data flow. Whenever I speak with high school or college students, I always tell them that if you don’t understand how to test your code, than you shouldn’t start writing the code. By the way, testing code doesn’t mean just testing the ‘success paths’, it means digging in and actually trying to break the code by using unexpected values or disconnecting things that your code believes should be there to successfully process whatever it is your creating. What happens if the call to the API fails because someone actually removed the location where the API is located or wiped out the service? What happens if you pass a numeric in where a string is wanted? What happens when the user fills out your forms with junk? What happens if they trying to inject SQL thru your forms? What happens if a bad actor attempts to use your API to sneak their way into the organizations systems? Plan for the worst and test to ensure it can’t happen – or at least reduce your risk exposure.
  7. Your Estimation Skills Suck: Sorry, but almost every new developer sucks at making estimates. You’re too aggressive, thinking you can do more in a limited amount of time than you actually can. You’re not thinking thru what it takes to actually design, build, test and deploy your code. That’s not a bad thing, you just don’t have the experience yet. Before you tell someone that you can have that code done in a week – check in with your mentor and get their feedback. Trust me, you don’t want to be giving out dates that are unreasonable. One there will be an expectation that you meet those dates, and two, you’ll get a reputation for not being able to deliver. Learn from your peers and let them help guide you – it’s ok to say, ‘Hey, I need to review this with my boss or my mentor. Give me till the end of the day and I’ll let you know when I can have this done for you.’.

Here are some additional thoughts on specific items mentioned above that dive deeper into understanding the data used by the system, the flow of data thru the system and code reviews:

- Back to Basics - Data
- Follow the Data - Software Design, Development and Testing
- Code Reviews - A Must for any Team!

Developing code is more than just walking into the office, plopping down into your chair and pounding the keyboard. You’re now an integral part of the success of your team, your department, your organization and your customer. Take the responsibility seriously, and remember that you’re in the role you’re in to add value. Set yourself up for success by understanding your role and doing the things that will make the team realize that you want to be a part of the success, not to steal time away and make their jobs harder.

If you'd like more information on my background: LinkedIn Profile

No comments:

Post a Comment