Advice to Myself When Starting Out as a Software Developer


As I look back to over a decade ago, there are a few things I wish I'd started doing sooner. Habits that could have helped made me grow faster and in a more focused way. This is the advice I'd give my younger self, who has just landed their first professional software engineeri

.

 

Canberk Demirci graduated from Bilkent University in 2018. He has been interested in software development since my primary school years. HE has developed many software projects since my high school years, some of which are; CngFiltre (2010): A filtering software for parents to protect their children from harm and inspection of computers and the Internet world, the first software in this field was in Turkey. BKMezun (2011): For the first time in Turkey, a web project that allows high school students to write their high school write-ups / annuals online. For nearly 7 years, we have developed many software projects for the industry with my business partner Altuğ. We are developing various custom software projects for many corporate companies in Turkey and the United States.

Take the time to read two books per year on software engineering
Every time I took the time to slowly and thoroughly read a recommended book on software engineering, I leveled up. By properly reading, I mean taking notes, talking chapters through with others, doodle diagrams, trying out, going back, and re-reading.

I wish I had read software-related books in my first few years as a developer. I only started doing this around year 5 of my engineering career. Books like C# In-Depth, Clean Code, and Javascript: The Good Parts all helped me elevate my craft at the time. It's not about me recommending these specific books - some of them are dated by now, anyway. What I do recommend is looking for books that go deeper than what you know now. This could be a book on a specific technology, or on software engineering practices.

When I read, I don't do it quickly. In fact, I do it rather slowly. I usually go a chapter or two in one sitting. I take notes or do highlights. When I'm done, I then recap and often discuss with others. I've also started writing book reviews on this site, mostly to reflect on what I've learned. I've picked up these habits the past few years. They helped me grow faster as an engineering manager: and this habit would have served me well as an engineer. Looking for inspiration for books? Here's the list of books I've read and am reading.

Why books over blogs, videos or talk? I'd actually say books on the side of those. Shorter formats tend to skim the surface compared to a book, for any topic. Books are in-depth, and well-organized knowledge. It takes me a few hours to write a post like this, but I've been working close to a year on my book on growing as a software engineer. I think of books as a form of slower, but more in-depth consumption.

Don't be ambitious: one book every six months is already great. Pick a book, and spend the time to properly read it. And after you've read a book or two, I also recommend the book How to Read a Book: The Classic Guide to Intelligent Reading. I'm serious about this recommendation.

2. Learn the language you use at work in-depth, to the very bottom
I started coding using PHP and some level of JavaScript for part-time work. At university, I was taught C and C++, both of which I had little love for. For my first full-time job, I started doing C#. I knew a lot of languages at the surface level, but none of them really well.

Two years in, I started to be bothered that I had to rely on senior developers when debugging my C# code. One of the developers who became my goto debugging buddy always seemed to know the ins-and-outs of the depths of the language. He recommended the book C# In Depth for me to study. And study I did. I went all the way to threading, how garbage collection and generics work, behind the scenes. I pushed myself through countless hours to understand covariance, contravariance, and other, difficult to digest topics.

Learning the language I used at work in-depth was one of the best decisions I made. At my first workplace, this was accidental and had to do with the senior developer inspiring me. However, this knowledge became an advantage both at work, and when interviewing for other jobs. Later in my career, I intentionally dived deep into new languages and frameworks. At Skype, I was hired as a C# developer. However, we needed to switch over to using JavaScript and WinJS. So I dived deep into JS and mastered WinJS to the point of me teaching it through a Pluralsight course.

The more languages you know, the more you can evaluate their strengths and weaknesses. By the time I moved over to iOS, I knew a few languages pretty well. When Swift came along, I briefly followed and participated in language discussions, proposing readwrite reflection to be added to the language's roadmap. Knowing the characteristics of the language made it easier to decide what strategy my team should use to migrate from Objective-C to Swift. And the more languages you know, the easier it is to pick up new ones - and go deep easier, when you need to do so.

3. Pair with other developers more often
I feel like pairing is out of style these days. When I started, both Extreme Programming with continuous pairing, TDD, and mob programming were popular things to do. Some of my biggest professional leaps came after pairing with people. These leaps were more significant than reading any book.

A memorable pairing was with a developer who gave harsh code reviews to everyone - including me. One day I had enough, and I decided not to reply on the code review tool, but to sit next to them, asking them to walk me through their comments. I ended up learning a lot - while also telling them I didn't think their comments were fair. They took note and suggested I pair every time I feel this is the case. This is what I did. This developer had a thing for performant code, and through my pairing, I learned about the ins-and-outs of potential performance bottlenecks - and I'd like to think I taught them about maintainability concerns, in return.

Another great pairing memory was doing TDD with another engineer, where we passed the keyboard between writing the test and writing the production code for it. We did this for two days, implementing a tricky part of the system. It's hard to describe how eye-opening this exercise was. We completely changed our approach midway as we made count of all the edge cases. And we also formed a strong bond with this developer, which would last for months after.

Join the mailing list
Subscribe to my newsletter and stay up to date on pragmatic software development and engineering career growth.

4. Write unit tests and run them against a CI
Senior engineers often talk about the importance of unit testing. But the whole thing seems so counter-intuitive. Why would you spend more time writing trivial-looking tests? This was my approach for testing for some time.

In order to appreciate the value of unit testing, you need to have that "aha!" moment, when unit tests you wrote to save the day. However, to get there, you need to grunt away, and write those tests, have them run against a CI. And you often need to do it for months, before you get that "aha!" moment.

For me, I had two of these moments. The first one was when I built the backend engine, as a side project, for a tiny online casino. The API was managing real money, and I was terrified of making mistakes. So I covered all my code with unit tests. The project was late - partially the tests to blame, as they took a lot of time. But it felt right to do it like this. I handed the project over to the customer at the end of the contract. Two years later, they told me how those tests had saved the team multiple times, who were about to push bugs in production - had it not been for tests breaking.

Cần bán website Social.itr.vn  ai thiện chí muốn mua gọi số 0949678047

What is stormgain

thue xe phan rang du lịch giá rẻ tại Ninh Thuận`````````dat nen phan rang giá rẻ **** can ho go vap - du an quan 9

Chuyên thu mua nhôm, thu mua sắt, thu mua đồng thu mua phế liệu giá cao hơn ngoài thị trường

* PrimeXBT What makes it so special and is it worth to try it out?