How to survive your first year on a Software Engineer path just after graduation?
Today is a special day. This is my 365th day at the company where I started working as a software engineer just after undergrad. I have decided to count this day specifically as a milestone. There is a first time for everything, after all. So I thought that I would compile the notes I took in my first year to share with anyone hoping to land a software engineering career after graduation. To cover each topic in detail would require an ultimate guide, so I tried to give a brief, high-level summary of all the main topics I found important. Sprinkled in you will find _my personal opinions_, along with literally random quotes and real examples.
Initializing
Did the picture of the running people above remind you that we were in the race or competition? No, that’s wrong. Yes, we are in a race that will not have a winner, there are; those who lose, those who are tired, those who watch from afar without doing anything, and those who cannot finish the race. There is no such a thing as a finish line in this race, and there will never be. That’s literally why it is not right to create a competitive environment between us. Competition destroys the teams. We have to help each other and support those in need. The question is: Which side do we want to be? Watching side? Falling side? Running side? Remember! Somewhere in the world, someone is working 10, 100 times harder than we are, and that will always be the case.
The purpose of this article is neither about programming advice nor coding best practices. We are not going to see “How to write maintainable, well-documented, well-designed code?”. We have more important things to do. These terms are our minimum expectations already, so let’s see how we can build on that base, in order to move forward.
Here is some inspirational, positive emotional music that you may want to listen to in the background as we dive into the topics.
1. Always Ask Questions
“The key to wisdom is this — constant and frequent questioning, for by doubting we are led to question, by questioning we arrive at the truth.” *
There will be a few hundred questions in your mind, and it will bother you as every day more and more are added to the stack. That’s why you have to always fearlessly ask questions. Start by asking questions. No matter how it is right or wrong, no matter how it is reasonable or unreasonable to you. There’s no such thing as a bad question if it helps achieve clarity in your mind. Over time, your ability to ask good questions will improve, but it’s a skill that must be developed. And, the best way to build that skill is to just start by asking questions. Building your question-asking skills is an iterative process. Although it varies from person to person, some learn linearly and some learn exponentially. The key point is to be aware of the errors in the question that you asked; we will use our errors in previous questions to inform us and improve the correctness of future questions that we ask. It is especially important to ask questions that you already know the answer to. This will prove that your thinking is on the right track and helps to verify the information. Moreover, when you can ask the same question to different people, it will reduce the subjective decisions one person will have to make by giving you a more informed view. Do not think you are disturbing, bothering, or interrupting people that you asked questions to. Use the power of proactive thinking.* Show and tell what you understand, give an opinion, put forward an idea in spite of other people. Try to learn to ask the right questions of the right people, at the right time. If you know all the questions and answers without any doubt, then you know what you are doing.
Example: Hey Lincoln, last week you told me that I am not allowed to use this new version in the internal systems. Does the project’s new license enforce restrictions for private use of software licensed under it? (a person who does not know exactly about open source licenses, unnecessary and missing information (which package?, which project?, which version?, why it’s not allowed?)) —He should not ask us a second question.
Action: Hey Michael, you told me that I am not allowed to use this new v2.0 version of Foo package in the internal systems due to open source license limitations. Does the GNU GPL v3 enforce restrictions for private use of software licensed under it? — (we got feedback regarding missing parts from him, iterated the question, and learned how to ask an almost perfect question)
2. Always Take Notes
“I think it’s important to always stay critical. But rather than dwelling on it and wishing I could change something, it’s important to just take those lessons learned and those new notes and apply them to the next thing.” *
Smart people learn from their mistakes. But the real sharp ones learn from the mistakes of others.* We all are making mistakes. Being human is something like forgetting, resisting, avoiding and refusing mistakes. We must accept and take the ownership & responsibility of our mistakes. Being behind the mistakes and admitting them will makes us more reliable, accountable and sustainable. So, what would success look like if we had the opportunity to take notes from our mistakes as soon as they occurred, or happened? Success would be inevitable, as long as we learn from our mistakes and do not repeat it again. Time is priceless for humans that it just can not be exchanged for anything. In retrospect, we should able to see how we try to make useful of that time. Which is why we have to start writing a daily activity log in order to remember what I we did all that day. Of course, it does not need to be like a diary; even a few words or sentences will be enough to keep our progress and remember that day after looking back years later. Additionally, you can also note the sentences that you have followed and spoken by someone you love. Just create a section called Custom Quotes and start writing there. Are you catch a so cool sentence in the movie or video you watching, podcast or radio you listening? Just write to the notes and try to read them in the future. You are going to say: “I am so glad I did this.”
Example: I accidentally deployed feature task that depended on some configuration resource that was not merged but supposed to be, which is caused clients to unable to update configuration dynamically for a few hours.
Action: What I learned from this mistake is that I have to deploy configuration resource just before related task deployment. I should definitely not do this again! I wrote this incident in my personal notes.
3. Soft Skills
“It is not the strongest or most intelligent who will survive but those who can best manage change.” *
We are not playing a game here. We need to be able to communicate well and clearly with other people. Be able to understand and empathize them. Be able to speak fluently and try cut the crab. Time is very valuable and important, we need to know how we can manage it. We must support the people and give them confidence. We have to make them believe in to win together, and show them that we are not playing alone this game. We have to give those people the awareness that this game is not about zero-sum-game.* This is not a one person race, further, we must think together, act together, furthermore, we have to take the responsibilities to move our team more forward. We must onboard and lead to our new colleagues and friends, we’d make they see the light.
Example: I can not keep up with the changes easily. I always think I am going to fail. I may not be able to explain myself to people in a good and accurate way. I may be get excited, stressed or panicked.
Action: Failure is a wonderful thing. Because the next time, you know what you are doing wrong. When you go from failure to success, you are actually a net gain. It does not do us any good to think like: “What if I fail?”. You could not, and you could not, but you feel that you are developing and improving within yourself. Let’s make the best of our own circumstances. Our own development depends only on us.
4. Continuously Learning
“Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young. The greatest thing in life is to keep your mind young.” *
We can breathe, we can blink, we can cry. Hack, we are all gonna be doing that. Developing ourselves is such a long-term and requires patience job that we do not see it in return for years. But if you keep going, at a certain point you get such an increase that there is a exponential curve… People who know how to learn and how to think can quickly resolve, understand and approach with scientific methodologies when they faced a whole brand new unfamiliar system and architecture. That is how we can be. Of course first step is would be to read a lot, work hard, know a lot and work right, know right. Additionally, it may not be a good practice to stick to a single source while working. Continuous learning does not mean that you have to learn and memorize everything quickly, whereas it means that this is the concept of always expanding your knowledge to gain new skill-sets and expertise on new fields or areas. Just try to give a hand to problem that you faced, instead of say: “ I do not know what it is for”, “I do not know how to learn this!” or, much bad: “Is this really for me?“. This is not continuously learning, remember, we are the engineering candidates. We should deep dive into what more we can do rather than just read and watch about the related subject or topic that we have been working on. It should be more important for us to learn how something works than to just trying it. It is more important what the purpose of the projects are and where they are trying to get to, rather than whether it works or not. No rest for the weary.
Example: I never heard of Docker. I do not know what is it for. It may be an unnecessary weight to learn new tech stack for this task, maybe we can try different ways. I may need to research this at a some time. — (still no action even after a couple months later)
Action: I never heard of Docker. I did a little research and realized that it uses container systems. In doing so, it is talking via the Linux system calls. Sounds interesting. Let’s see if we can do some research and explore some demo projects and use this in our project. In this way, we can learn the internal infrastructure of containers. In case of does not our permanent solution, may be we can try different things to get a successful result. If we succeed, we can write an article to demonstrate our architecture and share the results with our friendly community.
5. Learn Anti-Practices
“Today’s ‘best practices’ lead to dead ends; the best paths are new and untried.” *
Everyone wants to learn best practices nowadays obviously. This is inevitable. But… We all are missing some critical parts. One of the worst things a person can learn is that is to try to apply best practices in fist try or approach. We have a lot to learn on our journey. There are always will be a better approaches than best practices. The easiest learning methodology is learning by seeing someone else’s mistakes and errors. If you know the best practices in the industry, you also need to know the worst practices to really understand and see what the hack going on. We understand the value of good because there is a concept called bad. If it were not called bad, if good was the only concept we had, there would not be good either. We could not distinguish and understand what is good in reality. So when we recite the best practices in the documentation, it does not do much good for us; we need to know and understand why that best practices is a best, and where they are coming from. If someone comes to us here and builds our system more efficiently with their minds, the game would be over for us. Like the endless life hack. We would like to look at what how works and what is best practice from the documentation or related videos. But we really would like to? Can not we convince ourselves to do make it in more efficient way?
Example: We are using Debian container in production servers. Since Go able to get easily compressed into single static binary form duo to cross-compiling linker abilities, we can easily use scratch form in Docker. It is best practice because there are absolutely nothing in it, smallest image possible. It has also been described as best practices in many articles around the Medium.
Action: Let’s think for a second. The main reason of why we want to use scratch form is to want to move away from anti-practices. Since we are new companion to Docker, we have limited working ability do some separation process between good and bad practices. We have to work on it more. What was the real reason we chose to use a distroless image instead of Debian? What are the some anti-practices behind the non-distroless image? What problems will it solve? How will efficiency and security be affected actually?
6. Be a Writer
“Once you realize that documentation should be laughed at, peed upon, put on fire, and just ridiculed in general, THEN, and only then, have you reached the level where you can safely read it and try to use it to actually implement a driver .” *
The palest ink is stronger than the sharpest memory. Documentation is the one of the most utmost important thing to do. Do not think of it as a waste of time, never. Sometimes we pass up the importance of writing, we can not ensure maintain continuity in our software culture this way. We must be able to pass on the legacies we have written to the next generations that will come after us. We need to keep the long-term engineering culture alive by writing documentations. We must attach such importance to this culture that, the culture we created should be used even after years.
Example: We have just started a project from scratch. But in doing so, we never had time for documentation and we did not care. It was more important that complete project quickly and we could see the result this way. But when we shared this project to other communities, we had a hard time. We suffered with a lack of documentation. We had difficulty describing new contributors about the project and domain infrastructure.
Action: Even if it is considered to good to document everything actually, it is not that good expectedly. We have to struct the domain in such a way that the code itself sound like a documentation. It should make new contributers to see the light, there should be no inconsistencies and problems related to documentation. Contributers should also update the documentation at the same time. Users who will use the project should be able to find everything through documentation.
7. Deal with Uncertainties
“Projects with many uncertainties, it turns into increased aliveness, alertness, and creativity.” *
Working with uncertainties are not a reasonable work pattern. Because there are unknown or uncertain situations. We need to reduce or fix them before start a task. While doing this, we need not to reduce or fix it by hypothetical, but by obtaining real and reasonable information. What do you want to do? How are you going to get there? What kind of solutions will get you there? What are the differences between those solutions? Which one do you need to learn? Start doing it after you eliminated the uncertainties. We can identify the sources of uncertainties why and where exactly they occurred from. Is it because of “project management method?”, “project design architecture?”, “designing without non-anti-practices?” if so, however, may be we should check our review process to build better expectation aspects, trustable contracts, consistent information. If we do not make plans, we can not pretend to know. We need to remove the uncertainties by knowledge, not hypothetically. Please notice that, we should be looking for a permanent solution, not a workaround in order to avoid uncertainties to happen again. A small checklist, a small architecture change or a structure change may be a solution this, who knows? It is free to try and iterate to review process, isn’t it? What’s worse is than that the planned un-expected things is un-planned un-expected things. Have we really enough allocated time to deal with this? All of these may require additional resources and time to advance all of them regularly, eventually. Otherwise, we may have to survive with uncertainties. Finally, you can deep dive here, or get brief summary here.
Example: Scrum methodology can bring some uncertainties with it, unfortunately. The user stories we plan at the beginning of each sprint may not actually be what it seems, or what we understood, actually. In the development stage of the story, an uncertain situation may arise by the Devil and we may be get blocked easily.
Action: What about a creating a small checklist? Will we get blocked by another story that depended on this? Is deadline well determined? Has a decision been made between the teams so that the contract is consistent and final?
8. Do Not Have to Know Everything
“The cleverest people are not those who know everything, but those who know where to look for and find any information that is at the moment required.” *
The easiest question to answer that: we just do not have to know everything. We are not robot, yet. Try talk to other specialist people who has been working on very specific details. Understand the learning roadmap perspectives of their journey. You can deep dive with him/her even if you do not want to be expertise on that field. Our goal should not be to understand the subject excellent, instead, we can focus on how can we understand a brand new subject that we are almost foreign, how to approach deep diving techniques in correct and better way. Our goal has been working result-oriented from the beginning. We are not specialist, yet. But we really want to be? A specialist? A generalist? Both? * * A brute-force learner?* It absolutely doesn’t matter how you approach learning styles. Everyone has a different learning style, and it is important for us to embrace our individuality and the unique way to learn.
Example: We have been working with three different programming languages. Each project has different types of dependencies. I know the domains fluently, so I can work well on each projects. But I do not know how the 3rd party tools we use on projects work actually. How they achieve the performance, how were they written, how project architect was designed, how the whole structure works seamlessly?
Action: Perhaps this is a symptom of impostor syndrome. Are we really supposed to be know whole thing? Of course, when you are working with a realy good team, you can say to yourself, “I am not good as expected. I do not know anything” It is hard to avoid to say these. An engineer working at the same level as us may be writing better code all day and doing his job very well. Then let’s look at ourselves, what can we do outside of the just writing the code? We can contribute open source projects, write blogs, shoot the videos, giving conferences. But if the company goes crazy one day and says that the Foo programming language will no longer be used, we banned that, we will use Bar instead. It is expected that we will be able to adapt easily and become fluent in a couple weeks or months. See? Just do not try to reinvert wheel again. We do not need to know everything. Time is our companion. Let it flow.
9. Collaboration: Discover Communities
“If you want to go quickly, go alone. If you want to go far, go together.” *
We have to engage in the communities at large scale regardless of what the platform is, as long as we have a non-simplex communication between: Slack, Discord, IRC, Medium, DevTo, Reddit, Git services, mailing lists…* This is the utmost important way for us to create a continuously worldwide network, we can have an opportunity; to meet different friends from different cultures, to share and discuss simple or complex ideas, to create cooperation, to demonstrate valuable information, to find mentors and move towards mentoring path, to publish your projects, blogs and papers, to getting precious feedback from other engineers. Of course you can meet cohort of people with similar-ish skill levels to you, but what is more exciting and uniqueness than is that meeting people who have absulutelly nothing similar-ish skill-set to you; that is what really improves us, contributes us super new things from differenct aspects with new tech stacks, extending the our skill-set and abilities.
Example: We have been doing a PoC demo about how we could make our internal security pipelines better. We got a conclusion that there are also have some datas that we benchmarked with different tools and also a decisional balance table (a.k.a pros/cons).
Action: We were iterating through collaborative learning during whole process. We created a demo project, wrote an article about “why we needed, how we achieved, what if we tried, what we got” and shared with other people on worldwide. Got awesome feedback from different platforms and engineers, we noted all these and applied future articles and projects in order to iterate our abilities, eventually. *
10. I, Human
“Every decision you make, from what you eat to what you do with your time tonight, turns you into who you are tomorrow and the day after that.” *
We are obviously a human, especially if you are reading this. The difference between robots and us is that we have a pure crystal clear brain, which is proves that we have the ability to think. We have to realize that it is not all just about software even if we are in a simulator. Be well.* Detox your environment.* Sleep well.* Try eat healthy.* Listen the sounds of nature.* Explore your hobbies * and phobias.* Discover your keys to be success in the life.
Frankly, I do not think that writing, drawing, watching, playing, having fun etc. without leaving the comfort zone is bad for us. Of course, we will do things like that from time to time. But on the other hand, we will not hesitate to chase our dreams. We will not hesitate to express ourselves.
Example: Everyone sounds the same. Everybody’s competing against each other. What kind of race is this? Is everyone a slave to neo-capitalism? I feel like a random normal human among 7.594 billion people. What are the our main differences that will distinguish us from other people? How to create an impact?
Action: People have a desire to put themselves in the foreground: “So I have this, you don’t have it. Then, I am superior to you.” If the mental level of people decreases, the importance they give to physical objects increases. That’s what you are start racing for this now. However, let’s race over the effects we have created in the world. What are you up to? What have you done for humanity? What did you do for yourself? What are you doing both of materially and spiritually? Rather than coming out to humanity with the things that everyone has, we should come out with knowledge, experience and what we have brought to the world. People always lose this, in everyday life. People competing with each other about unnecessary spending.* It may be better to isolate ourselves from these people and join together with people in communities who think in our style, and we can take care of our own business.
Finalizing
365 days is not fair enough to call us a “Software Engineer”, obviously. We are expected not only to know these, but also to be able to apply them in professional. Are we really apply that basic engineering principles? * * * There are a lot to do. A lot to create new things. Software engineering is quite a large area. The area of the future. We are the ones who like to solve difficult problems and explore new things. We have a long long, bumpy and difficult road ahead of us. This will be long journey.
Since of those will be _my personal opinions_, it is okay if any of them do not suit you. But I literally would like to expect you to write why you agree or disagree with that thing. So we can find strike a happy medium by have an exchange of ideas at the comments section. Feel free to write down anything you think.
“Thank you, and have a very safe and productive day!”
Happy New Year 2021! 🎉
May we meet again.
