What you need to know to be a software developer
Published on
The day before yesterday I received an email with a simple question:
“What do I need to do to start and thrive in my web developer career?”
The direct answer is easy: study, train and learn from experiences. In eagerness to be done with my inbox, that’s what I thought of answering.
But it’s a good question, and if you start to dissect the idea a little, you realize that while the straight answer isn’t wrong, there are some points that will be more stressed throughout your career, and if you can strengthen those points, it will help not only in your entry and stabilization in the market, but it will also serve as a base when you are already experienced.
So it pays to expand the initial answer a little:
Language and framework
Choose a language you like or feel minimally comfortable with. If in doubt, see how the language market is and try to narrow down to which one makes the most sense for you, based on your tastes (“compiled or interpreted?” and “strongly typed or duck typing?” are questions that can help you decide). If your goal is to increase your employability, look for most widespread languages that contain a good number of job openings.
Having decided on the language, see what is the most widespread web framework for that language. In Java we have Spring, in Ruby we have Rails, in Python we have [Django](https ://www.djangoproject.com/), and so on. You don’t need to go deep into the framework at first, but knowing how it works and, mainly, its specific vocabulary, will facilitate your communication with other developers and will help you find answers on the internet.
Don’t save time on this step. If when trying to solve a problem you find yourself running into a lack of intimacy with the language, it pays to go back to the drawing board and study the basics a little more.
(you will need to learn other frameworks in your career, but learning one in depth will make it easier when you switch to a new one)
Crud
There are code generators, and tools that automate the creation of simple cruds, but in the beginning the ideal is to build one manually.
Create a simple application that creates, reads, updates and deletes data in a database. Focus on SQL databases first, and although your framework has some abstraction to make it easier to communicate with the database, familiarize yourself with SQL queries and commands. No need to delve into it, but know how to make joins and try to understand what makes one query fast and another slow.
With Crud up and running, look at the code and see if there are any improvement points or ways to simplify what you’ve done. Try to improve the readability of your code, and as much as possible, keep things so simple that they don’t need comments.
Communication between services
With the first application done, a good second step is to create a second application and have them communicate. Think of some use case that deepens the crud (maybe save the request source ip in a record for historical data?) and try to implement it in a separate application from the first one. This will force you to think about the interface between your two applications, how to organize shared information and what information should be shared.
Here it pays to take a look at RESTful concepts, which will help you think of a standardized interface that is a little more market-oriented. See what it means and what parts you find interesting to apply (it won’t be all of them).
Cache
With both applications already working, consider that the read operations from one of your applications will receive many requests. This will add extra load, and you need to think about the impacts this will have on your architecture. Use some load testing tool (such as apache ab, Jmeter and Gatling) to understand where the stress points you need to optimize are.
The standard solution for this type of problem is the implementation of a Cache. Study the concept and see ways to apply it to your systems.
It is worth paying special attention to the problems that arise when inserting a cache into your architecture: Assume you have cached a user, and then made an update to the row. How will you make the cache know what the latest version is?
Messaging
With the read issue resolved by the cache, consider the next problem: suppose that write operations are now being heavily used. Re-employ a load testing tool to understand what symptoms and issues arise from this overuse.
The most widespread solution for this is to throttle the processing to be done asynchronously. We usually use some messaging system for this, like Rabbitmq or Redis. The idea is to queue the requests so as not to overload your database.
Again, it pays to analyze what problems have arisen by adding this new component to your architecture. Which operations of your application can be executed asynchronously, and which ones demand immediate execution?
Next steps
That would be the basics for web developers today. Go deeper into the themes described here and expand your range of tools for solving problems. I have given some suggestions for implementations, but not many. It pays to take a look and find other popular names on the market. And, in addition to what I’ve already said, it pays to see:
-
Automated tests: whether unit, integration, or component… the important thing is that you understand what they are, what they are for and how to implement them. Try building tests on what you’ve created to see what problems you find.
-
Environment with many nodes: In the scenario I described above, there is only one node for each system. Consider that in the real world you will typically have more than one. How does this affect your cache? How does this affect your database?
-
English: You don’t have to be fluent, but knowing English will boost your career. Much of the documentation will be in English, and new practices and frameworks will emerge first in English. Most importantly, most of the questions you have are already answered in English on stackoverflow. Practice asking the same question in English and Portuguese on search engines and you’ll find it much easier to find answers in English.
Below is an example of a problem, in case you have difficulty imagining a use case for your crud.
Customer Crud
Assumptions:
- Consider only the backend part. No need to develop html/form, just REST endpoints
- A customer consists of name and age only.
- Open IP geolocation API https://www.ipvigilante.com/
- Open weather API by geolocation https://www.metaweather.com/api/
- When performing the weather search by geolocation, if there is no specific city of origin, use the closest result.
Your task is to develop the REST services below:
- Create a Customer
- Change a Customer
- Query a Customer by id
- List all saved Customers
- Remove Customer by id
When creating a client, for statistical and historical purposes only, find the geographic location of the person who made the request, using the IP of origin. With the geographic location, check what is the maximum and minimum temperature of the day of the creation request in the place of origin IP. Save this information and associate it with the customer resulting from the origin request.
Keep in mind that the Customer by ID service will be highly executed.
Good luck :-) If you have done this example problem, you can contact me by email to ask questions or talk about the solution.
Comments
I feel that comments on specific blogs have been dying down as the times goes. If you have any questions or want to talk about the post, contact me through the below links.