Questions Newly Hired Developers Should Ask To Become Contributors More Quickly

In my last article (https://csharpdeveloper.wordpress.com/2021/05/24/how-companies-can-facilitate-the-onboarding-of-entry-level-developers/) I wrote about things a company could do to improve the onboarding experience for entry-level developers.  In this post I offer some questions that newly hired developers can ask to improve their own onboarding experience.  Not only do I suggest that you ask these question, I think you should actively seek the answers to these questions if you have idle time.  Knowing the answers to these questions will improve your understanding of how things are done at the company and impact how you write code and spend your time in development.

• What do I need to do to be considered a contributor to the company?
  • One of your employer’s biggest concerns is the unknown number of weeks or months it will take before you provide more value to the company than the cost of your salary.  No matter how talented you think you are, you almost certainly are costing the company more than you are worth for the first few months you work there, if not longer.  And the reason for this is because a senior developer could complete all the work you did in your first two months in one-tenth of the time and with higher quality.  So, if that senior developer has to spend half of their time during your first two months assisting you, then the company is going to be nervous that you will continue to cost them more than you are worth.  However, take heart in understanding that your employer hired you knowing there would be an upfront cost, but in the hopes that you would soon be able to contribute more than you cost, and be able to contribute without requiring a lot of time from the other developers.
• What percentage of my time will I spend using my JS/TS skills, my server-side skills, my database skills, (the skills that you hope to spend time on improving/learning)?
  • This question really should be asked before you get hired unless you really need a job soon.  If you are craving to write TypeScript code but learn you will be tasked with writing database SQL for the next year, then you should definitely let your employer know your preferences because they may be able to make adjustments to improve your employment satisfaction.
• Who will be using the software I work on?  Is it external customers or internal employees?  Are we developing applications for other businesses?
  • Most entry-level developers I hired rarely asked such questions, but I don’t think less of them for not asking.  The reason I think newly hired developers should ask these questions is because it helps give the developer a better understanding of how the software works and is deployed.  It helps the developer correctly assess the trade-offs between application concerns such as security and performance and the impact and risks of making mistakes.
• How is the software that I will be working on deployed?  Is it “in the cloud”?  It is on premise?  Is it web apps or desktop apps or phone apps?
  • Like my note on the previous question, this helps developers assess impact and risks of making mistakes, and also understand what technologies they may need to learn.
• What is the process for our source code to get to deployed?  Do we commit to a source control?  Do we manually run build and deploy tasks?
  • In some companies, developers write code, check in into a repository, and then forget about it.  In other companies the developer guides the code all the way into the production environment.  The answers to these questions will help you understand what is expected of you and your role in the process and identify some things you need to learn.
• Are there unit tests or static code analysis or other steps in the build pipeline?
  • Companies with more highly evolved software development practices often have static code analysis and unit tests.  If your company does not have them, this identifies an area where they could possibly improve by adding them.  If they already have these processes, then you should probably learn how to use them and gain their advantages.
• If there are tests, how do we write and manage them?
  • Unit tests provide a lot of value for teams that continue to work on and evolve a software product.  If your team is already using them, you should learn how you can add your own unit tests as part of the first lines of code that you will write yourself.
• Are there database changes that might accompany our code changes, and if so, how is the deployment of the two together managed?
  • Many software products store data in databases, and often those are relational.  If you make code changes that affected how the data is stored, then the change to the data store needs to be migrated into production along with your code changes.  This can be challenging in many environments so you want to understand the impact and how it can be managed.  You may decide in some cases that you will write your code in a different way to implement a feature just so that you can avoid a database change.
• Is there a QA/Test environment that we can deploy to, and is there staff to test our changes?
  • This helps you understand how much responsibility you have for testing your code changes.  Not that you shouldn’t always test your own code changes, but often a change you make could affect many scenarios, and a QA team can help reduce the time you need to spend testing.  When a QA or Test environment exists, it tells you that the company is fairly concerned that bugs don’t get introduced to the production environment.
• Who do I work with to review my code changes and to guide me toward writing good code?
  • A specific single person signals to that person that they are expected to work with you and therefore will dedicate time to do so.  When there is “shared” responsibility, team members often hope that someone else on the team will help you because each team member is usually already very busy; and they each assume someone else is less busy than they are. 
• How do I receive the tasks that I am going to work on, and how does the team track my status on those tasks?
  • Most software development shops use a white board or some task management software.  There are many free task management tools on the Internet like Trello, but most teams will have something more sophisticated.  Learning how to correctly use these products is important for you in learning how to manage your work and to help your team members see that you are contributing.
• How do the users of the software know all the features we put into it and what bugs exist and what bugs have been fixed?
  • Some products, especially software for internal employees, may not track this at all; but software for sale that is used by external customers probably does.  As you fix bugs and add features those usually need to be shared with customers and understanding how that process works will help you contribute good explanations and information to the customers.
• Who do I contact for non-technical questions about how features in the software should work?
  • Hopefully you have a mentor to help you write code, but you often need to talk to the users of the software, or a representative of those users, to better understand exactly what they would like to have done, or to collaborate with them about the costs of what they asked for and alternative ways to solve their problems.
• Is there documentation for users of the software that I can learn from?
  • This is a great way for new developers to get up to speed more quickly on what is expected of them.  Seeing the software from the end user perspective will help you understand what needs to be accomplished in the code you write.
• Is there documentation about the software architecture and coding guidelines?
  • Internal documentation can help you make appropriate decisions, not just about formatting but also in helping you to identify that some problems have already been solved and you can, and should, re-use the existing proven solution.
• Can I install software on my computer, or do I need to ask permission first?
  • Before installing software, get permission.  Some companies provide a location with tools already approved for use.  Many companies do not want you to download software from the Internet due to the risks that the software may contain malicious code.  They will desire to first approve it.  You don’t want to be the person that downloads the malware-laden software component that infects the company’s network with ransomware.
• Are there policies I should follow before adding third party dependencies or components to the software we are writing?
  • Although a StackOverflow post may show how easy it is to include a third party JavaScript library in your web page to solve a problem; it might not point out that the license requires that the JavaScript library only be used in open source projects and any software that uses it should be considered open source.  This can lead to lots of legal hassles.  Make sure that you approve third party frameworks and tools that you use and honor their license agreements so that you don’t get your employer into expensive legal trouble.
• What are the security threats I should be aware of when writing our software?
  • If you are asked to import an XML document into an application and process it, you should probably learn how concerned you should be with making sure that XML document does not contain malicious script that could do harm to the computers on which your code is installed.  XML documents are just one example; many inputs and processes can introduce security risks.  Learn early what the security threats are and also how your team correctly addresses those threats so that your code doesn’t open the door to malware.
• Does our software need to adhere to compliance guidelines such as SOX, PCI, or HIPAA?
  • Like addressing security threats, some of the code we write, particularly some of the design and management of sensitive information like passwords and credit card numbers, has to be handled with extra care.  It is likely that good practices have already been identified and you can borrow code from elsewhere in your applications to handle compliance guidelines; and it is best to learn the right way to do those things before writing code that just works.
• Will I be exposed or working with any sensitive data and how should I handle it if I will?
  • Patient and customer data sometimes ends up in test databases so that developers have real data to test with.  However, you should take care with the data and make sure it is not shared in printed pages, or on test web sites, or exposed to other people that have not signed the waiver that they will treat the data as confidential.  Understand that some data you are dealing with should not be discussed outside of your business context.

How Companies Can Facilitate the Onboarding of Entry-Level Developers

Despite a shortage of software developers, entry-level developers can tell you that it is difficult to get hired.  Companies are often reluctant to hire entry-level developers for several reasons that include:

• They don’t want the risk that an entry-level developer may not have the skills to do the job.
• They don’t want to invest in bringing an entry-level developer up to speed and then see the developer go to work for another company.
• They don’t want to pay for the time it takes for entry-level developers to become producers instead of costs.
• They don’t want to lose productivity of current staff devoting their time to bring entry-level developers up to speed.

Development teams also find it challenging to provide tasks for entry-level developers to work on because there are so many things an entry-level needs to understand before doing any coding. A lot of that is the processes surrounding coding and how those processes are performed in the organization.  Below is a list of items that many companies want developers to understand.  Often only the coding items were part of the training the developers received in school.  Companies want a developer that:

• knows what IDE to use, how to install it, open it, update it, and be productive with it,
• understands the technologies used by their app in order to get things done:
  • The code language, UI language, data stores, best practices, frameworks, and IDE,
• knows how to test their code locally,
• knows how to commit code changes to a repository and update from a repository,
• knows how to use repository tools to review other code and find code changes,
• can write unit tests,
• can start and run unit tests locally,
• proceeds cautiously at first, not checking in changes without being certain,
• will not check in code changes to the production pipeline accidentally,
• understands there is a build process, and be able to run a build on their own,
• understands the process of how their changes get deployed or used,
• understands there is a production build and how to initiate it,
• understands there is a way to deploy for QA/Test (maybe),
• understands they may be able to deploy directly to production,
• can find the task management system that has the list of tasks and features and bugs they are to work on,
• can manage their own tasks on the task boards,
• knows who to talk to for any task requirements as well as task priority and also if the task is right/ready for them to handle,
• tracks their time – how much are they spending on each task,
• can assess what is a priority, or who to ask to get that answer,
• understands the business domain and what the software “does”,
• understands the development priorities (security or performance or maintainability or customer satisfaction or just functional),
• follows the patterns already in use in the code for solving problems,
• knows how to use our Requirements and Design tools and processes,
• gets to work on time,
• is focused on their work during working hours,
• is eager to learn,
• is friendly with everyone.

When a company commits some time to building a good onboarding process for new developers, they can greatly facilitate the onboarding process and make it less difficult to hire an entry-level developer. 

• Create documents and videos of the applications the developer will be working on
• Create documents and videos of your software development processes
• Assign each new developer a contact person they can go to for any question.  If you are hiring several developers, ideally each contact person will serve that role for just a single new developer.  Also, the contact person should be someone on the same team that is very accessible to the new employee.
• Schedule some one on one time for each new developer with each team member.  Often, you can use this time for an existing team member to share knowledge about the company and software with the new developer.
• Prepare their computer, physical environment, and computer software before they arrive for their first day.  Make sure the application software, and unit tests if applicable, can run successfully on their computer.  Have all of their security accounts ready for use.
• Have mentors reserve time to spend with new developers almost each day for the first two weeks.  Don’t just hope to “squeeze it in” as needed.
• Remind existing team members to contact the new developer(s) when they are about to perform a task or process that the new developer needs to learn so the new developer can join them as they go through it.
• Put off some simple fixes/enhancements on your task board for a few weeks to reserve them for the new developers to do.  Give the new developers a chance to commit a real code change on their first day.
• Finally, create an onboarding checklist with links to videos and documentation about each item on the checklist.

Here is an example of an onboarding checklist in a google document: https://docs.google.com/document/d/1K5jw1OgQDbLiXt9UvLR9Qnm5Pj9fWj-brp6_FiTUWJw/edit?usp=sharing

If you want a faster start for your own onboarding checklist, I recommend you make a copy of this Trello board and customize it for your own company: https://trello.com/b/h9eTMg4E/onboarding

The way I recommend using this Trello board, is to make a column on it for each new hire.  Each employee can work their way down the board, marking items done on checklists and changing the “Labels” on a card when it is completed.  Many items on this board anticipate that a mentor will work with the new employee to discuss the item (cards with the “Mentor” label).  Other cards have a label named “Complete Independently”.  Of course there is still a lot of work for you to do in preparing documentation and customizing the board for your own development shop, but hopefully this helps you get started.

Git for Microsoft Access Databases

I wrote about this project previously (Track Changes to Access Form Properties in Source Control (Github) « Rob Kraft’s Software Development Blog), but am happy to share a more complete solution. If you would like to have Source Code Control such as Git or Subversion or TFS to track all the changes to a Microsoft Access database, the code in the github repo mentioned below has the code you need. This code is free for you to use in any respect (MIT license). Just copy the code into a module in your Microsoft Access database, run it, and it will export everything.

By everything, I mean it will export the following information from your Microsoft Access database into files:

• Code behind Forms
• Code behind Reports
• Code in Modules
• Code in Classes
• Properties of Forms
• Macros
• Properties of Reports
• Table Definitions
• Queries
• Database Option Values
• Database Property Values

You can get the latest version of this code https://github.com/RobKraft/AccessUtilities

Efficient Software Development Surpasses Both Waterfall and Agile Development

A product owner asked a developer to add a date picker to the web site in place of a text box. The product owner said it would be nice if the calendar just displayed the five weekdays. The developer knew he could add a date picker but didn’t know if he could exclude Saturday and Sunday from the calendar. He didn’t find any options in the date picker control to exclude the weekend, so he created a new control. It did not render as well across all browsers, and behaved a little quirky sometimes, but it showed only weekdays. This took the developer two weeks to complete, after which he showed it to the product owner. She was not happy with the rendering problems and was very disappointed to learn it cost two weeks to develop. The product owner said she would rather have a control that worked better even though it included weekends, especially if that control only cost a few hours to implement.

The parable tells a tale of software development. It is a sad tale, and a common tale. Many would consider it an example of a project failure. The product owner paid more money than expected for a solution that was not as good as she hoped it would be. This type of problem occurs often in waterfall software development, but it also occurs in Agile software development.

Yet, this problem could have been prevented. The developer and product owner should have communicated more frequently. The product owner should have made it clear that she would like a calendar that excluded the weekdays, but only if it could be completed by adding no more than two additional hours of development. And the developer should have understood that the business is usually willing to settle for less than the asked for if the price of getting exactly what they asked for increases the cost exponentially.

Teams that desire to develop software more efficiently will identify this communication problem and make attempts to reduce the chance it will happen again on future projects. The teams will do this as part of their goal to improve their processes, not because the Agile principles provide this guidance. Software developers should strive to develop software more efficiently, and if following Agile principles helps facilitate that improvement then software developers will follow the Agile principles, but it is important to avoid putting the practice of following Agile principles ahead of efficient software development. Agile principles are a tool we can use to develop software more efficiently, but Agile principles are not the goal of our software development process. Great software developers don’t care if someone considers their processes to be agile or not agile, as long as they are efficient. I feel it is important to stress this last point, because it is the key takeaway from this article: Our goal is not to become an Agile software development team; our goal is to develop software more efficiently.

Developers that already practice Agile development may recognize that the characters in the parable were not following Agile principles, and if they had done so, they would have experienced better outcomes. That is certainly true if the teams were following the principles of Agile, not just some of the common practices. Too often, companies, project managers, scrum masters, and developers adopt practices such as “Daily Standup Meetings”, “Two-week Iterations”, “Retrospectives”, and “Measurement of Velocity” and believe that makes them Agile. But none of these practices would have solved this problem. Following these practices does not make a team is Agile, nor is being Agile the goal. The goal is efficient software development. Agile principles can help you get them, but don’t let your focus on Agile principles cause you to lose site of the goal.