Problem: You feel your job depends on you delivering a solution written in a specific programming language and of the same standard of quality as your teammates. Alternatively, obtaining a job in the first place depends on your proficiency in a specific programming language.
Solution: The text suggests picking a language and becoming fluent in it, as it will be the main language you will be using for the next few years to solve problems. It’s a difficult choice to make, especially when looking for jobs that may been looking for specific skills and languages. It’s “important to carefully weigh the options, as it is the foundation upon which your early career will be built.” One good way to gain experience and become fluent in a language is to actually have a real problem to solve, and to “seek out opportunities to create feedback.” Becoming fluent in a language allows you to start working more on test-driven development, allowing you to check your assumptions and aiding development of new languages.
This pattern has good advice, and it’s not the first time I’ve heard someone suggest working on one language and perfecting it instead of trying to learn multiple languages at the same time and expect to be fluent in each one. An interesting tip from the text was building a toy application in the language you’re trying to pursue a job with, one that your prospective employer would be able to access. Good learning experiences come from solving real problems, school gives you a good foundation to build upon and learn from the problems you solve in your professional career. Working in the field and running into real problems, the ability to work with other people and learn from them is a big part of gaining skill. I think Java would be a practical choice to become fluent in as it’s a high demand language that receives a lot of bad press but it running on 3 billion devices. The book also mentioned the community behind these languages and all the resources you have at your disposal. They suggest taking advantage of the support network you have and attending local meetings related to that language.
In this blog post, John Sonmez talks about “soft skills” and how they can help you become a better software developer. Here are some tips from the author:
- Instead of trying to learn several programming languages at the same time it’s better to have one language that you know in and out, that you are comfortable writing.
- Structure your code well by writing “good, clear, understandable code that doesn’t require a large amount of comments because the code itself is communicative.” – John Sonmez
- Having a good understanding of object-oriented design and managing complexity as most popular languages rely heavily on object-oriented design and analysis.
- Understanding how to create algorithms, and how to modify known algorithms to match your specific needs.
- Understanding of data structures like arrays & vectors, linked-list, stacks, queues, trees, hashes and sets. These are important to know well, especially if you are being interviewed.
- Knowing a development platform well is a good idea because some places design for specific platforms (PC, Mac, etc)
- Learning a framework, or a complete stack. “A framework is simply a set of libraries that are used to develop code on a particular platform or on multiple platforms.” and “A stack is a set of technologies, usually including a framework, that are commonly used together to create a full application.”
- Basic Database Knowledge, how to add, modify, delete and work with different database systems.
- Source Control, understanding how to use tools like GIT.
- Testing, more often projects are being created in small increments and tested as they go, this is allowing developers to catch bugs before they begin to cascade.
I chose this resource because I’m always looking for information on becoming a better software developer and want to become an asset to wherever I dedicate my work. Some of the information is general information but I do think it’s important to work on maintaining these core skills to improve the quality of your work. I learned the importance of working on knowing at least one language very well, along with knowing one platform very well knowing how to implement popular data structures, writing good algorithms and knowing when to use what. I learned the importance of object oriented design and how prevalent it is today. I learned about frameworks and stacks and what they are, and the importance of understanding how databases work. I also learned that more recently developers are being expected to know how to test their code, especially with agile testing.
In this blog post, Justin Albano gives advice on working on code written by others. It can be tough making changes or adding to code that you did not write yourself, another reason why clean code is so important, it helps other have a clear idea of what’s going on. The author notes pitfalls that you should watch out for when working with someone else’s code:
Our Ego: We think we know best, but must respect the code and original author.
The ego of the original author: Working on code written by someone else may lead to questioning decisions made by others which must be met with working with the original author.
Fear of the unknown: Many times you are going to be working on code that you know very little about and will be responsible for those changes. It’s important a framework is built to ensure changes can be made comfortably with no worry.
Some techniques for maintaining clean, functional code:
1. Ensure Tests Exist When current tests are not sufficient, you must create them yourself, which can be challenging. Other times, having tests provided for you, you can learn from the tests what the intent of the code is.
2. Talk to the Person Who Wrote It Communication is key, if you have the chance to talk to the author of the code you’re working on you can get some insight if you’re having trouble.
3. Remove All Warnings This ensures quality of code, and reduces code rot.
4. Refactor Changing the internal structure to make it easier to understand without modifying behavior.
5. Leave it Better Than You Found It Do your due diligence when it comes to maintaining quality for you, and future people working on the same code.
I chose this resource because it gives advice on working with other people’s code, working with existing test cases, or adding your own. It reinforces the idea of clean code because you should leave the code better shape than you found it (if that’s possible). I feel the article had some good information that I will definitely use in the future. I will be working with code that was written by someone else, and will need to write test cases for changes made to the code and maintain it still functions the same. I learned techniques for dealing with code written by others, and doing my best to respect the original purpose of the code.