DEV Community

Discussion on: I changed career to software development without a CS degree, Ask Me Anything!

jsanddotnet profile image
Justin J Ask Me Anything • Edited on

Congratulations. Really pleased for you.

Great question. One I hadn't envisaged answering. I've added a lot here. Please don't let it put you off, or concern you :)

For me, the first few weeks were hard going, but really exciting. I had only really worked on my own code base before and diving into someone elses was quite a challenge. After some days (ahem, weeks if I'm being honest) that didn't go well as I'd have liked, I found a pretty good formula, which I try to use to this day.

Things take time. As long as you're trying to improve, you'll do great!

1. Don't expect too much from yourself!

I felt pretty stupid at times, expecially as my boss was one of the most talented developers I've ever worked with. He could write a one liner to do what had taken me all afternoon and 100 lines of code to get working. Fortunately, he was really nice about it. He'd just say "We've all been there. You'll get it soon enough.". I'd study what he'd done and tried to use that technique in future.

Remember when you first started driving? Did you just jump in and go. If you are like me, it was a fumble to start and took repetition and learning until it became second nature.

Driving is easy compared to coding.

Don't expect to be a master from day 1. Even experienced developers who are new to complex systems can take a few months to get up to speed.

2. Don't be afraid to ask for help!

You will find differing levels on willingness from colleagues on this one. Hopefully your manager will assign you someone who will help, but otherwise, seek someone, or several people out.

I have always found someone willing to give me an overview (what does this thing do anyway? who is the customer? who are we integrating with? How are we integrating with them?).

Also, I've always found someone willing to go through code with me. In fact, you learn a lot just by watching someone else code (esp shortcuts and debugging tips). If the screen flashes and does something magic, don't be afraid to ask what they just did.

An interjection here - some companies have systems that are complicated just to get the source code and build! (hidden configs, magic settings, unusual dependencies).
Don't be put off. Ask someone and they'll probably say "yeah, it took me ages to get set up - here's how I did it". Then they'll give you 1/3 of the answer and you'll have to ask again.

I actually found my boss would give me a harder time if I'd wasted company time trying to work something out myself instead of asking someone and getting the answer in seconds.

3. Try not to feel time pressured.

Ok. This is hard.

As a newbie, you'll feel pressured to bring results fast, but you are new and the company should allow you time to get to grips with the system. As long as you're trying and not playing on Facebook, they should cut you some slack as part of the learning process.

One of the key things to remember with software development is that sometimes you can create a whole system in a week, sometimes you will spend a whole week achieving absolutely nothing.

In fact, maybe only in software development can you feel such joy from spending 3 days working to get back where you started!

4. Start with something small.

As a newbie, you'll be really eager to make a difference, but new systems can be hard to understand.

Even as an experienced developer, when faced with a new system, I start with small tasks and build up.

Typo needs fixing - I'll do that. It seems really trivial, but it gets you into the system.

You start to get an understanding of where stuff is, how the projects are layed out and how they relate to each other.

If you sign up for a major task up front, you have to understand all of the above AND work out how you are going to implement the solution. It's a lot for any brain to handle.

5. Break it down

When you start with bigger tasks, it can be a real head smasher.

For me, the key thing is to break it down. Make a little test project for yourself that just does one part of it.

For example (and not even the worst company would give you this early on), say I had to incorporate a new type of Authentication into an existing app. I would:

A. Spend time fully understanding the existing authentication in the system. Literally, I wouldn't write any code, just research and debug the existing app (this could be days on complex systems!).

B. Learn the new type of authentication.

C. Implmenet the new type of authentication in a test project that ONLY has that type of authentication.

D. Update the existing project with the new (now fully understood) authentication.

Some companies might not afford you such time, but I would rather do something properly with no bugs than have to fix critical bugs on a feature I don't understand.

Also, I usually find this quicker than just trying to fudge something in direct, as there are usually loads of trip hazards that you haven't anticipated.

6. Invest in reading materials/ courses

When you see what the company's tech stack is properly (i.e. what you will be using day to day), get books on the subject, read articles, or do Pluralsight tutorials to help you get up to speed. Putting in the extra effort early on is hard, but sets the foundations for many fun years coding.

And of course, Google + StackOverflow is the base for almost any developer these days :)

miketr33 profile image

Wow! Thank you so much for such a detailed answer. Some really useful information in here. I am going to make sure I have this handy throughout my first few weeks. Particularly when i'm feeling stupid or slow :)

Thanks again :)