Skip to main content

Great coder != Great software engineer

Great coder != Great software engineer
How do you change that sign into an “=” sign?
As a software engineer out of college, your initial goals are to get use to the professional working environment.
Once you get passed that first hurdle, then it is all about the programming or coding skills. You want to improve your .NET C# skills or Java skills or NodeJS skills or Python skills or database skills. You want to learn the frameworks around these programming languages better and you want to learn different ways to optimize your code and apply different design patterns in your implementations. These are great skills to have and in a lot of cases required skills to have. The most important thing is that you are enjoying what you are doing.
At this point you have reached that level that will give you the right to label yourself as a great coder or a great programmer. However, there is still more to go. At this time your main focus is programming and you may be lucky that your technical lead and software engineering manager are abstracting a lot of things for you and shielding you so you can focus on programming most of your work day.
Don’t feel rushed that you need to advance vertically in your career. You need to feel comfortable where you are, and you need to follow your gut feel. When it’s time for you expand your horizon, it is your choice to make. It is all part of becoming a great software engineer.
Now it’s time. Willingness to listen and learn from other senior software engineers, tech leads, solutions architects and software engineering managers is the key to turning yourself from a good coder into a good software engineer. This is the type of stuff you cannot easily google. You need to be patient. You have to approach it with open mind and realize that there is no book “Experience in a Nutshell” that can help you expedite this process. After some time doing things the right way becomes the second nature. In fact, it later becomes harder to NOT do things the right way.
What you will learn is:
  • * What it takes to develop and deploy robust applications at the enterprise level to production and then maintain it in production.
  • * SDLC (Software Development Life Cycle)
As you learn more and more and software engineering concepts come as second nature to you, that’s when you know you graduated and joined the club of great software engineers.
Thank you for reading. Please follow me here on SoftwareEngineeringBlogger.com or check out my personal site: http://www.almirsCorner.com
Almir Mustafic


Labels:

Comments

Post a Comment

Popular posts from this blog

Brand New programming language and one solution OR …

Brand New programming language and one solution OR Two existing programming languages, one solution for EACH? I understand that there is no right or wrong. It all depends on your software architecture, team structure, team skills and other factors, but I still want to explain the scenario as it may look familiar to some. Let me explain. Let’s assume that you have microservices and common libraries in two major programming languages. You have some teams who are experts in one and some teams experts in the other programming language. Now you need to come up with a solution for a scenario that all teams will need to leverage. Let’s assume that your cloud platform has an off-the-shelf approach for this but it is supported by a 3rd programming language that your teams do not have much experience in. What is the right thing for your organization and not just from the technical point of view? A) Do you embrace what your cloud platform gives you off the shelf and implement thi...
Post a Comment
Read more

Architecture Diagram for ...

ARCHITECTURE DIAGRAM representing interactions of your family of microservices is one of many important things to achieve the enterprise-level microservice architecture and microservices. After going through the design and contract definitions of your APIs/microservices, your team needs to put together a single diagram that explains the interaction among microservices (owned by your team) and how these microservices interact with other teams’ microservices. This is basically the blueprint for your team’s work and this picture needs to be constantly updated as you are evolving your services. What does this give you? It gives you the big picture view and it allows you to detect good or bad patterns that you cannot see when you are deep in your code. For example, you may be able to see that you are doing too many direct API calls for something that could be done with pub/sub approach. Almir Mustafic
1 comment
Read more

Programming / Software Engineering  — Think Paper, Paper, then Code

Most of the software engineering problems are solved in what I call the high-level brainstorming sessions. We basically walk into a meeting room and white-board our thoughts and come up with solutions. When things start falling apart, you better believe this happens in the last stretch of projects and it does work.  Now the issue is that we as programmers do NOT do the similar type of exercise before a line of code is written ? I typically see developers get requirements in the form of a document or a user story or in the form of walk-by requirements. The next thing I see on developers’ screens is code editors or IDEs. Is that the right thing to do? You may say that you are advanced enough and that you like to dive into coding right away, but this happens even to the best of us. We fall into this trap and rarely step back and review our habits. We have to go back to fundamentals. What did we do in school?  Professors taught us to write down our thoughts and to show what...
Post a Comment
Read more