8 Tips to Become a Stand Out Enterprise Developer

Most companies are constantly on the lookout for the best talent. There are many software developers, but there are only a few who really excel in their area of specialty.

In this post, we did a little brainstorming and came up with a list of tips that will help you be an enterprise developer that stands out from the rest.

1. Design

  • Fully understand the problem: Design phase is fundamental and for an enterprise developer, mandatory. Before getting hands-on with the implementation, understanding the problem to solve should be the first priority. Ask the right questions to the right people and read carefully any user stories, documents, etc, that might point us towards thoroughly understanding the problem.
  • Sketch the solution: Always put in some time (hours) to sketch a diagram of classes, methods, objects, workflows, functions, changes, etc. Take notes of the considerations determined during this phase. This is so when coding, later on, we don’t miss anything.
  • Consider dependencies: Always take into account the dependencies our functionality or system may have. In this phase, we should be able to discover most of the impact our code will cause.
  • Patterns: Ask yourself if a design pattern is applicable to the problem we are currently solving. Design patterns are solutions to common repeatable problems and ours might fall into that category. Using a design pattern offers multiple advantages (these are out of the scope for this post). Tweaking a pattern may also work or even using one as an inspiration for our own customized solution.
  • Design takes time: A good design may take time, even more than the actual coding of the solution, but, may also guarantee a solid and elegant solution.  So, don’t skimp too much time and effort for this phase.

2. Code quality

  • Use correct data structures and flow control statements: Characteristics  such as performance, immutability and multi-threading must be taken into account when picking the right data structures for our solution. The right flow control statements are the ones that  help us keep a balance between readability, simplicity and lines of actual coding.
  • Self-explanatory code: The code we generate should be clear enough so it doesn’t require much explanation. Another developer should be able to read it and understand it without many comments. Things such as avoiding ternary operators and using meaningful names for variables or methods are encouraged, so readability of the code is not sacrificed.
  • The Simplest solution will often be the best: Do not over-engineer your solutions. Always consider, first, the simplest way of solving the problem. It will probably be the easiest one to understand (for you and for others) and to maintain. If the simplest is not the best solution, you can at least start growing from there.
  • Learn and follow standards: Many organizations have documented coding guidelines, coding formatters, best practices for software development, compliance guidelines, etc. Always go over these documentations, to deliver a product that satisfies the company’s best interests. If there is no specific rules outlined, get informed on standards established by the technology and/or community you are working with and stick to it.

3. Exception handling

  • Try/catch/throw: The code generated by an enterprise developer must be robust. There should be no space for unhandled errors and corner cases that were never foreseen. The use of try/catch blocks are typical of well-developed solutions.
  • Finally: Always consider including finally blocks. It’s a good practice to clean up any allocated resources, close any connections and execute any code that is required to be executed no matter what.

4. Logging

  • Log levels: A good and caring developer will always know about the different logging levels available and will use them in benefit of him or herself and people that will be in contact with the software (QA’s, DevOps, support staff, and even final users).
  • Print the right data: Use info level to log messages that may provide information about steps being executed. Use debug for logging information such as input parameters in a method or variables generated during computing/calculations within the application that may help troubleshoot if required. Use warning level for alert messages or potentially harmful situations. Use error for any caught exceptions along with a stack trace and any additional and important information related to the error.

5. Debugging

  • A great tip that may help us find a solution easier and faster is “almost” programming in debug mode. Running and testing your application on debug mode will allow visualization of workflows in our code by checking expected behavior and playing with our code to verify edge cases. Take advantage of features such as setting certain values during runtime to validate your software with cases that may be hard to test otherwise.

6. Code review

  • Make code reviews a habit. Not only will they help you validate the correctness of our code, but also identify possible bugs on early stages of development, as well as a mechanism to share interesting solutions and even business knowledge among other team members.

7. Commits

  • Any check-in to a version control system should have a very clear and descriptive message of the new code we are including. Add just the right amount of information for it: any feature or story id, what does it includes or fixes.
  • A commit should be atomic and should include just one change/fix/feature (nor more nor less). This practice may contribute to simplifying integration processes, avoid integration issues and help in keeping the system stable.

8. Testing

  • Unit/functional/integration tests: Today, all developers should get closer and closer to working with TDD methodologies. Unit, functional and/or integration tests are required in any piece of software considered “enterprise”. Writing and keeping up-to-date tests should always be part of the maintenance of software in general.
  • Manual testing by developers: An enterprise developer can never skip testing his own software. Reserve a couple of hours just to go over any “happy” and “unhappy” paths of your application once we think our features are coded completely and all unit/functional/integration tests are fully running and passing. Put your code into challenging test cases to guarantee the code you produce is as bug-free as it can be.
  • QA oriented developers: From the very initial phase of software development, each team member must be committed to the quality being delivered. As an enterprise developer, you must think very QA oriented. QA is not a separate silo, but is part of a cross-functional project team.

Having said all the above, no recipes are written in stone for software development, nor does development get easier with time! There are always new challenges and technologies in the pipeline and a wide variety of projects. The experience you gather brings a lot into the game, yes, and great technical skills help with the job. But, as we’ve heard lately in so many of our conversations with colleagues, what weighs most is the attitude each of us has. A good attitude can make a big difference, but a great one will make you really stand out (in this field, or any other)!

To read more about the author please see this post here and stay tuned for future posts by Mariana!

Are you already a stand out enterprise developer? Gorilla Logic only hires the best. Check out our careers section and like us on facebook. 

 

 
Mariana Santamaria

I've been a software engineer since 2007. I had the opportunity to study computer science and took the risk without a doubt in my mind. Now I see it was meant to be! I'm in love with programming, but also in love with so many other things too! As far as I can tell, being an engineer is my career, but it also defines who I am in many ways.

Related Articles

Ready to be Unstoppable?

Partner with Gorilla Logic, and you can be.