tips for new devs in the workplace.

S

sp4ceman

Well-Known Member
Joined
Jul 11, 2011
Messages
418
Reaction score
0
Location
outside your window.. no really.. keep looking...
when you're new you aren't expected to know anything. when people are giving you the tour of the code base or whatever don't try and complete sentences. just listen. if you're always trying to display your knowledge or whatever you're spending your time thinking about things to say to sound smart instead of listening to what's going on.

spend the first week with a notepad writing **** down and asking questions when you don't understand. ask about anything just make sure you are listening to the answers.
 
On a serious note, new devs need to really ask questions. And if its a complex task, get up off your chair and let the experienced guy sit at your work desk and step you through it. Too often have I just given up because the new guy hogs his seat and expects to be told what/how it should be done - this can take an age. Sometimes it feels like trying to explain to your gran over the phone how to install a program on her PC. Some things are best shown, not narrated, saves everybody time.
 
Been at My company for 4 years. I am no longer the Junior.

I still let senior Devs "drive" when showing me something. in the same way I "drive" when showing them things i have learned.

most important tip I have ever gotten and what I believe should always be implemented by everyone, no matter the experience:
"Never be afraid to learn something new, the world we live in is always changing, change with it."

I subscribe to 4 different blogs just on the language I write in, I read them everyday, because someone, somewhere has already struggled with the problem you have right now.

then my personal tip, TEST. then TEST again. then go out of your way to break your own system, then TEST some more.
then find the person with the least knowledge in the system you are building, OUTSIDE the dev team if possible, and let them run through the system without giving them ANY training, see what people will do wrong, and build for that.
then give it to the guy who breaks every system, and let him find your logic holes then fill them.

the biggest problem we face as Dev's is that we understand what the code is supposed to do, so we will never test in a way that the code is forced to do something it is not supposed to do.

with my SO in marketing and me in dev, for different companies in different fields of interest, I can let her run through my systems to see what a brand new user might do. you would be surprised at the amount of times I have gone "the system is not built for that, but still people will try doing that, lets prevent that with a nice little pop up message here..." and then she goes and does something even more unexpected and gets around all the traps I put in place.....
 
can i ask you if you use something like tdd as a methodology? because i will tell you straight up that it is impossible to make a system do something it shouldn't if you have developed it with tdd.

what you are explaining.. that process where you make some code, your gf comes up with some other crazy ****, then it breaks then you fix it is literally the red green refactor process that drives tdd.

only with tdd you have an extra set of code that explains the rules and definitions of the system so when you're looking at the code and there is a weird where clause or some bizarre logic all you do is mess with it and see what tests break in order to find out the why.

this prolly doesn't belong in this thread and it's getting a bit evangelical but tdd people. tdd. it is prolly the single most important thing i have learnt when it comes to dev. and the south african community needs to get on this ****.

whats weird is in most non dotnet languages it's not even a question anymore. node and rails have that stuff built in. you can't find a tutorial without them mentioning testing and cucumber and how to test. but over in dotnet land we are still debating it.

last week i attended a dev evening and they had prof barry dwolatzky from wits out. the dude is a legend and he knows his **** but i was shocked. his talk was entitled something about "using quality to boost productivity" and the best he could suggest was code reviews in a formal manner.

2014 and our experts are talking code reviews as though it's a breakthrough in process. if you're not doing formal code reviews in your workplace right now you are doing it wrong.
 
Last edited:
Thanks, can see now that trying to sound like a smart ass could be irritating, just so happens that I did this not so long ago.

Advice taken.
 
sp4ceman said:
2014 and our experts are talking code reviews as though it's a breakthrough in process. if you're not doing formal code reviews in your workplace right now you are doing it wrong.
Click to expand...

We don't do code reviews am I doing it right ?
 
its not only for checking up on people. when timmy is on leave or having a sick day it's handy to know why he did what he did or how he was thinking when he did it. our reviews are more knowledge sharing than anything else although we have added some juniors to the team lately so it's a good quality check as well
 
sp4ceman said:
its not only for checking up on people. when timmy is on leave or having a sick day it's handy to know why he did what he did or how he was thinking when he did it. our reviews are more knowledge sharing than anything else although we have added some juniors to the team lately so it's a good quality check as well
Click to expand...

I've had the experience where these "seniors" believed their code was more efficient, when run through various benchmarks their's landed up being slower.
 
sp4ceman said:
im confused. were you told to change things in a review only to have it then run slower?

that's not a reflection of the process of code reviews that's a reflection on that senior..
Click to expand...

I don't agree with what you just stated.

But he was going through code and instructed me to change it, as my implementation was no efficient. But yeah i basically landed up he knew bugger all about threading.
 
sp4ceman said:
well that moment there is a knowledge share that happened only because of a code review. you could talk about the code, bench it and show the results. hopefully the dude was gracious enough to learn something new.
Click to expand...

No, he wasn't, but i just ignored him and did it my way in the end.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X