![[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Viewers also liked
Viewers also liked (16)
Similar to Dont Be A Noob
Similar to Dont Be A Noob (20)
Recently uploaded
Recently uploaded (20)
Dont Be A Noob
- 1. Don’t Be a Noob How to get past entry level in your Job Leonard Miller YAPC::NA 2009 June 23
Editor's Notes
- In this talk, we will discuss a few things that you can do to get beyond 'beginner' or 'entry level' status in your Job and Career as a Perl developer.
- Some of you may know me from Frozen Perl in Minnesota the last two years. The rest of you probably don’t know me at all. I work at the University of Minnesota and because of this, we get our fair share of student employees. Most students are intelligent, and willing to learn what you have to teach, but once in a while, we get one that thinks that he or she is smarter than the Entire team of developers. They ignoring the fact that I work with folks who have been programming longer than they've been alive. They think they know everything.
- It is these students that really cause the most grief, and by trying to prove how smart they are, they cause more work for everybody else. They break that break every guideline because they think its ok for them to do it, not realizing that most coding guidelines are about maintenance and code readability. Here are the five things that I would say classify a noob, and we will talk about these In the next few slides
- Being a newcomer. The new comer is just that. They are the first definition of n00b. The way to get around this and not earn the title of noob is to follow the example off my Freshman year in highschool. The highschool I went to, had a reputation of hazing and humiliating freshmen. So amongst 1800 students in the school, I stayed in the back of the pack, and tried not to get noticed my freshmen year. I stayed away from the other freshmen who were acting like the stereo-typical freshmen, and low and behold, I had an uneventful year.
- So while you cannot fix this, you can mitigate it by laying low and not standing out as the newcomer. you will be the newcomer until someone else is the newcomer, and possibly longer.
- This really is what it means to be a Newbie. You don't know what exactly you are doing, when compared to the non-noobs. Of all the students I worked with, there was one, I'll call him BK, because he thought he was the King. BK would come from his classes and tell me how I am doing our project all wrong, because his professor said it was better to do it another way. Now I am all for college classes, but if you have a degree in computer science, you will understand that the classes don't teach you everything, but they teach you the fundamentals. They teach you about scope, and big O notation, and various types of sorting algorithms. They don't teach you the experience you need to know how to determine what the relationships should be, and how the tables should be layed out in a large Relational Database.
- BK one day had an html form that looked like this: when this form was being submitted, I suggested that he used POST since my experience had taught me that GET requests have 256 character limit. He was conviced he was right and interrupted me, telling me he knew how to do it. Rather than have a fight with him there and waste my time, I let him come to me two hours later thourougly beaten when his web form wouldn't update past the 4th line.
- What can you do about this? Find the older programmers in your group and become their friends. Learn Everything you can from them. Ask them design questions that you think you know. This is hard work, but it is worth it. The older developers have knowledge and Experience that you can really learn from them.
- This point lines up with my Freshman story of shutting my mouth and not getting noticed. Another student that I had the (dis)pleasure of working with would answer any question you threw at him. The problem was that he didn't always know the answer to the question you asked, but he would answer the question none-the-less. I got so fed up with him that I started to ignore all input from him, because 1/2 the time he was correct, and 1/2 the time he was wrong. If you don't know the anwer to a question, don't answer it. Tell the truth that you don't know. That is much better than making sh*t up. BK also did this, but not as badly as my answers-all student. He would berate other students, because they weren't selected to be the 'programmer student'. He also saw our application as a way to pull pranks on the users of the application. On several occasions he would put "javascript: alert('something')" into a while statement, and annoy the piss out of someone trying to do their job.
- So, the guideline here is to answer questions truthfully even if you don't know, and to allow the more experienced programmers answer questions, so that you may learn from them. If you find yourself talking more than listening, you should try listening more.
- This is the one thing here that you can address without being in your new entry level job. I am all for college classes that teach you about scope, and big O notation, and various types of sorting algorithms. Get Programming Perl, read it like a book. Read Damien's Perl Best Practices, and follow his guidelines. Until you can justify not following his guidelines with experience, don't break his rules. They are not golden, but if you are breaking a rule, either you replaced it with a different, similar rule, or you are doing something that could cause you trouble in the future.
- BK, had a habit of using the word "perfect" when describing his code. He once used the word perfect to described his rounding function that didn’t work right. He just didn’t know to look for and use the CPAN modules available. You can mitigate this by learning. You are here, so that is a good start. If your employer pays for college classes, you should take advantage of that. Read appropriate books. Learn
- 5. doing dumb sh*t I could go on and on here, but as much as it hurts, I will keep it down to a single example. Our perl project had mixed perl and html in the code. Not the best design, but we were waist deep into the project and its what we had. Most of our html tables looked something like this:
- One day BK decided that he was going to learn XML, so he decided to use xml because his professor told him that java plus XML = WONDERFUL. So he loaded about 7 CPAN XML modules, looped through the dataset, adding each row to the XML doc, created an xslt document that lived on the server, transformed the XML to HTML, and then printed the document. The programmer who inherited the codebase from us, stripped out all of his fancy XML/XSLT code and replaced it with the regular print statments, that ran in 1/2 the time without loading all the XML goofieness. Now I am not against XML or anything he did, but he decided that for this one Runmode, that he was causing a huge maintenance cost for us, and the xml offered zero functionality that we didn’t already have. I could go on and on, but I won’t
- Other dumb things to avoid that NOOBs sometimes do: Simply put, don't copy and paste your code. Create libraries and subroutines. Use them. Don't run queries or scripts in production. If you are a n00b you should be running everything in a test environment. The last thing you need is an UPDATE sql without a WHERE clause. Don’t commit your code to the codebase with out thourougly testing it first. If it was a complex solution, ask someone else to look at your solution. they might have a better answer for you. Don't code backdoors/practical jokes into your application. It's immature and irritating. Don't assume your code is 'perfect' just because you didn't find a bug with it. BK once managed to screw up a function that would format a dollar amount for display, and blamed me, because his was 'perfect'.
- This talk can really be summed up in one sentence: Listen and learn from the more experienced programmers around you. If you are listening and learning, then you will be gaining experience, you won't be talking out of turn, gaining knowledge, and will hopefully prevent you from doing something entirely stupid.
- This talk can really be summed up in one sentence: Listen and learn from the more experienced programmers around you. If you are listening and learning, then you will be gaining experience, you won't be talking out of turn, gaining knowledge, and will hopefully prevent you from doing something entirely stupid.
- This talk can really be summed up in one sentence: Listen and learn from the more experienced programmers around you. If you are listening and learning, then you will be gaining experience, you won't be talking out of turn, gaining knowledge, and will hopefully prevent you from doing something entirely stupid.