Whether you're a beginner programmer or at the stage of your career where you're looking to improve, or even reconsider programming altogether, this article will be useful to you. Over the next few sections, I provide tips based on my 10+ years of software development and IT management.
Can you set up a dummy database for testing? If you're unable to set up a local environment that mirrors the staging or production environments, you'll have to depend on a systems administrator, lead developer, or even Director of your organization. Make sure you fully understand that these resources are already strained performing other tasks. If you want to deliver on your promises in time, you have to make sure you can depend on these resources at a moments notice. They may not be there to help you move forward when you need them, leaving you with nobody to blame with the project manager is asking you why you haven't written or tested all of the program's functions.
Learn how to quickly and systematically eliminate bugs. Have a process where you can narrow down the issue and not go on wild goose chases. Debugging is like carving out a sculpture. It is a subtractive process. You start with a large block, and whittle your way down.
|Server isn't responding||Is it plugged in? Is the internet up?|
|Code produces an error in the browser||Have you identified the file? Which block of code is malformed?|
The idea is to start big and quickly narrow down the issue, until you've identified the offending line of code or conditions. Learn Quality Assurance best practices. Learn how to use debugging tools effectively.
When the pressure is high, you don't have time to retread the same paths. Take notes while you walk down that path the first time and reference them, in the future. Share them in the company wiki and allow others to optimize those notes. Something you think you can recall may actually be more difficult when it comes time to execute. You want to avoid a scenario where you make promises based on that assumption because you'll be thrown into a high stress situation where you have nobody to blame but yourself.
It's just a waste of time to have to relearn an arbitrary set of steps. However, before you take notes, make sure you understand that the process adds to your development time. If you're 100% sure you're performing a process you will never need to revisit, sure, it's OK to skip the note taking.
Automate your job functions in order to produce faster, eliminate human error, and produce more consistently. As important, be strategic with when and who you communicate this to. If you invest the extra time and effort to to automate a particular job function, leverage the time you've freed up to optimize the automation code and give yourself breathing room. Communicating that you can now perform your job two times as fast may feel good in that moment when your boss' eyes light up, but it will hurt in the subsequent weeks when you realize you are now expected to consistently deliver at that rate.
Even worse is if you set this standard with no compensation whatsoever. What toll will that take on your mentally? Will it breed resentment? Will you come to hate your job? Consider all of these questions prior to any communication. At the end of the day, the company cares about profits, not people.
You'll want to operate in ebbs and flows. Crunch for 4 days, clean up and prune your code for 1, or some relative measure of this. Whatever technical debt you're accruing, do so strategically. Be aware of how much technical debt has accumulated, and communicate that up the ladder to incentivize the company to invest in housekeeping to make this debt manageable. Always frame this communication with the profitability and efficiency of the company in mind.
If the company makes the decision to skip housekeeping, make sure to communicate the risks and how it could impact future deadlines.
The open source engineering community is a large group of people who share information, just like we do at the Codebox Systems blog. Utilize resources like search engines to hunt down this information and utilize it to wade through the sea of technology that's out there. Leverage software documentation, forums, bug reports, and anything you can find. If possible, give back to the community and provide solutions for open issues and bugs.
Use a password manager as early as possible. This is not a strategic decision that has anything to do with the size/scale of the company. This is easy to realize when you try to count all the accounts you, as an individual, manage.
- Desktop Password
- Mobile Password
- Personal Email
- Company Email
- Company Basecamp
- Online Banking
- Online Payroll System
- Software License Keys
- Server Keys
- Domain Name Service
- Hosting Provider
- SSL Service
- SSL certificates
- Online Shopping
- Source Control
- Online Project Management Tool
- Online Benefits Service
- Webinar Software
- Skype / Video Conference software
- Company chat client
- Database keys and passwords
- Third party service API keys
Your job is going to throw you into high pressure situations. You do not have time to hunt down passwords with a deadline looming and a project manager breathing down your neck. You'll also be able to provide company passwords stored in your password manager to others.
Your passwords will be more secure.
If possible, share a vault with only company passwords. This way, when a company password is updated, everyone in the organization has access to the most up to date.
Don't take on every burden. You can put the burden of certain deliverables and expectations on your boss. If you're boss doesn't want to hire QA, it's not completely your fault if bugs are found in production. But if your boss doesn't hire QA because you promised that the product would be bug-free, you need to be able to test as well as you can code, that you have the capacity to do both, and you're happy with the compensation for performing two different roles, simultaneously. You are responsible for meeting expectations, but you set those expectations first with the promises you make.
If you lack experience, providing realistic estimates is extremely difficult. You simply haven't run into enough scenarios or failed enough times to anticipate all the potential speed bumps. Early on in your programming career, your manager should be padding your estimates if he or she knows how to mitigate risk. An inexperienced manager will take a junior developer's estimates, communicate it directly to stakeholders, and leave the developer to fend for themselves if the target is missed. An experienced manager will organize a meeting with the engineers and stakeholders, cultivate an open discussion in order to allow the best ideas to surface, and then give the team room to think critically about the risks involved. This allows for:
- A more realistic estimate to be provided
- Information to be shared among the team
- The best resources to be allocated
- An environment where team members feel as if their ideas as valued, further incentivizing them to take ownership of the project and help each other move forward.
If the company can't afford to have these processes in place, you'll need to give yourself more padding and even have a backup plan in case you don't deliver on your deadline. No matter how many resources at your disposal, there needs to be some strategy in place.
Technology moves fast, with old software being replace by new software before it takes the average person enough time get up to speed. Master fundamental programming concepts because they apply to all languages. Understand the problem each language and library is trying to solve. Create your own libraries. Never stop educating yourself.
What do you think of these tips? Do you have any tips that worked out for you? Feel free to share them in the comments below.
- The Self-Taught Programmer: The Definitive Guide to Programming Professionally
- Node.js Design Patterns - Second Edition
- Automate the Boring Stuff with Python: Practical Programming for Total Beginners
- Learning Python: Powerful Object-Oriented Programming
- Beginning Programming All-In-One Desk Reference For Dummies