Unrelated image from pexels.com to make this post look nicer in social media shares.
If you’re a programmer and someone asks you to solve a problem, that means the problem needs to be solved by writing code, doesn’t it? That’s what programmers do, right? Not necessarily!
Knowing how to write good code is a huge part of being a good developer, but so is knowing when not to write more code. Take this question from reddit for example. If the problem is that you need an online store, writing one from scratch is the last thing you should consider. Needing to be able to sell stuff online is not a unique problem. It’s not even a slightly unusual problem. The more common the problem you’re trying to solve, the better chance somebody out there has already solved it and will sell you the solution for a reasonable price. In the case of an online store, that’s probably WordPress and one of about a zillion ecommerce plugins, or one of many (so many) ecommerce platforms.
To keep beating on the online store example, let’s talk about why it’s such a bad idea to write one from scratch. First of all, writing a whole store from nothing would take ages. If your goal is to sell things, spending weeks if not months building your store and getting everything working just right would be a huge waste of time. And don’t think you’re done just because the store works – if nothing else, you’re going to need to apply security updates to whatever it runs on, and let’s be honest, there will be bugs and you will need to fix them :) Sadly, the more lines of code you have the more potential bugs you have. The more code you write, the more code you have to maintain.
Another reason you shouldn’t write a store from scratch is if you’re taking people’s money, you have to be absolutely sure that you keep their payment details and personal information safe. Protip: security is hard and if at all possible, you should make it someone else’s problem. If you use a reputable plugin or platform, you can be reasonably sure all the security stuff has been done correctly. Aside from security, there’s also uptime to worry about. If your store goes down, you don’t make any money and you get to freak out about what brought it down and how to bring it back up. Again, if what you want to do is sell things, trying to figure out why your store went down is a terrible use of your time. Also, if you use existing software that thousands of other people have already beaten on, you’re a lot less likely to have surprise downtime.
And don’t forget requests for new features! If you build your own store, it’s going to be pretty basic at first. Sooner or later, you’re going to want fancy stuff like sales, limited time offers, discount codes, etc, etc. Yay, more stuff to worry about finding bugs in! Those aren’t even the really scary examples, either. If you decide you want to internationalize your store with descriptions in the local language and prices in the local currency, you may need to rewrite huge parts of it. And then worry about finding bugs in those parts, because there are so many fiddly little details you can get wrong with internationalization.
Developing your own [fill in the blank] can enormously expensive, too. Sometimes it is worth it to develop exactly the thing you need in-house, but sometimes it’s really not. The great thing about commercial off-the-shelf software is that the vendor can sell it for a tiny fraction of what it cost to build it because they can sell it over and over. Even the very newest junior dev’s time still has a value – is a week of their time still cheaper than buying the solution? Is having precisely the feature you want going to make more money than having that junior dev work on something more directly related to your business?
As developers, our first instinct is to start writing code when we want to get something done. That’s totally normal and you shouldn’t feel bad about it. It took me ages to learn to ask whether we actually need more code to solve a problem or whether there’s a simpler workaround. What I wish more developers were taught in school is that our job is to solve problems, not to write code. Yes, sometimes writing custom code is the best solution to the problem, but sometimes a simple wordpress plugin or a cron job is all you need :)
Unrelated image from pexels.com to make this post look nicer in social media shares.
A question I’ve seen a lot on java programming forums is “Should I get a certification?” Like every other programming question ever, the answer is “it depends.” Don’t worry, I’m going to explain what it depends on and how you can figure out whether or not it makes sense for you to get a certification.
First of all, I want to admit up front that I’m skeptical about programmer certifications. I’ve seen excellent programmers with certifications and I’ve seen far from excellent programmers with certifications, so I don’t believe having a cert tells me very much about whether you can code. That said, it’s not going to hurt you to have a certification on your resume, so if you have access to funding for retraining or anything, go for it!
What I believe most people really want to know when they ask if they should get a certification is “Will it help me get a job?” The answer depends on what companies in your area want, but fortunately, that’s really easy to figure out. Research! Hey, I didn’t say it was going to be fun :) What companies want is not some big secret, it’s going to be directly in the job descriptions they post. The trick here is not to look at two or three postings from companies you’re already interested in and call it a day. You’ll get a much more complete picture of the qualifications that companies in your area want if you look at a wide range of jobs both at your current level and above it – you’re not planning to be a junior forever, are you?
Another way you can research is by going to user groups and meetups and asking around. People who already work in the industry are going to be able to tell you things that aren’t in job descriptions, like “the last person company x hired who didn’t have a certification was the boss’s niece” or “company y’s job description mentioned certifications were a nice to have but they were actually perfectly happy with my example code”
Speaking of interviews, they can be a reason to get a certification even if local companies don’t specifically ask for them. If having a certification would make you feel more confident and you can get one for a reasonable price, go for it. The more prepared you feel going into an interview the better you’ll do answering questions, which a cert can help with even if you never get asked about it directly.
Whether you should get a certification also depends on what kinds of credentials you already have. If you have a programming related degree or diploma, I wouldn’t worry about getting certified unless local companies really want certified employees. If you’re trying to switch careers, a cert could really help and is likely to be a lot cheaper than going back to college or university.
It’s a little bit of a tangent, but something certs can legitimately be really helpful with is telling you what to learn. It’s totally overwhelming to do a couple of tutorials online and learn just enough to freak out about how much more you have to learn. Certifications can narrow that down by giving you a nice tidy list of stuff you should know. Fortunately, you don’t have to actually get the cert for that, you can just read the list of topics the exam covers and learn them on your own. Then you can prove you know them by building something that uses those concepts and/or writing about them. As a bonus, nothing convinces an interviewer you can code like showing them your code.
Should you get a certification? Will it help you get a job? You can find out yourself by reading job postings and going to user groups and asking around.
I’ve been thinking about interviews lately since I know a number of recent grads who are looking for work (ping me if you’re looking to hire a junior dev). Interviews can be really intimidating, especially when you’re trying to find your first development job. They still make me nervous and I’ve been at this programming thing for ten years.
Unrelated photo from pexels.com
I’ve only participated in a couple of interviews from the employer side of the table and I’ve never run one myself, but I’m going to tell you what I learned anyway :)
One thing that you might not know is that interviewers don’t always get their other tasks cut back very much to make up for the time they spend interviewing. Don’t take that the wrong way, that doesn’t mean they hate doing interviews and want you to fail, it means they want to do the fewest interviews they can get away with and then stop.
Seriously, for the interviewer the ideal outcome of an interview is that the candidate is great, they can tell HR to send them an offer, and they can stop interviewing. Programmers don’t like getting interrupted anyway, and an interview and debrief with the other interviewers and then typing up notes for HR is a big chunk of your day.
The interviewer really and truly wants you to be great. It’s the most convenient way the interview can possibly go for them, and it really is awkward for everyone when an interview doesn’t go well. Nobody wants to watch someone crash and burn in an interview. Obviously that sucks a lot more for the interviewee, but it’s not really a great time for the interviewer/s either. Even if you’re not amazing, nobody wants to watch you fail.
Because the interviewer wants to stop interviewing, they’re looking for reasons to hire you, not reasons to turn you down. Nobody wants to make a bad hire, but ideally we can just make a good one and call it a day.
Another thing you should know is that culture fit, particularly if you’re interviewing at a startup, is extremely important. When the entire dev team is four people, the next hire makes a much bigger difference than it does on a team of twenty. On the one hand, that can make you nervous, but on the other hand, there’s nothing you can do about whether you’re a fit, so there’s really no point worrying about it. I know, I know, that doesn’t really work on me either. Do as I say and not as I do and all that :) You wouldn’t want to be on a team you don’t get along with anyway, so the best thing you can do is let your interviewers know who you are.
Something that took me quite a while to learn is that you are interviewing the company just as much as they are inte rviewing you. You’re not the only one who gets to make a decision here, the company you’re interviewing with needs to impress you too. I personally recommend asking about things like work life balance, whether they believe in crunch time, what their expectations for a new dev are, how they handle it when something goes wrong, exactly what time you’re expected to be in the office (startups are often flexible on this, but it’s good to know how flexible they are. Some offices also start at unusual times to stay in sync with head offices in other timezones), what the interviewer’s favourite thing about working for that company is, etc, etc. There are plenty of lists of standard questions to ask employers in an interview, take a look at a couple for inspiration and ask about the stuff that matters to you.
Employers really do like it when you ask questions, it shows that you care about which company you work for and aren’t just desperately trying to find anything that pays. Much like in dating, desperation is just not attractive. Employers like to feel special too :)
The one thing I really want everyone to take away from this blog post is that if the company is worth working for, the interviewer is on your side. They want you to be great so they can hire you and go back to work :)
Everybody screws up sometimes and I wish we talked about it more. One of many things that I think scares off new programmers is the belief that if you ever fuck up then you’re just not cut out to be a programmer. That’s totally not true, even experienced professional programmers make mistakes. All making a mistake means is that you tried to do something that’s actually difficult, it’s not the end of the world.
Look at some relaxing sheep from pexels.com while we talk about making mistakes.
In the spirit of helping other people not freak out about their own mistakes, let’s talk about some of mine.
Early in my career I came up with a truly terrible design for a portlet (remember portlets? No? Okay, I feel old now). If I remember correctly it was supposed to provide a friendly UI for people to create their own report queries, so there were all sorts of rules about which kinds of values applied to each field and how fields could be combined to keep track of. This was back before I really understood that requirements never ever stay the same, and after a couple rounds of changes my design was a real mess. If nothing had ever changed my house of cards might have been okay, but since things did it started to crack and warp under the strain.
What did I learn from that one? That requirements always change and your design needs to handle that, and that it’s always a good idea to have someone else review your design before you start building, especially if you don’t have a lot of experience. Designing software to handle requirement changes is something I’m still working on and something that could fill a whole book, let alone a blog post, so I’ll just say that asking yourself what happens if you need to add more rules or take some away is a good start.
Another thing I messed up I already mentioned in my post If it’s hard to explain, it’s probably a bad idea. To recap really quickly, we (the backend team on the project) came up with a scheme to sort players into rooms that was basically impossible to explain to non-programmers. Actually, I’m not sure it ever even made sense to the devs on the client team either. I bring that one up again to drive home the point that design is hard and you’re going to screw it up a lot before you get good at it.
What I learned from that mistake was that designing in isolation can really trip you up. That design seemed like a good idea to us backend devs in isolation, but if we had run it past the rest of the team first we could have figured out it was confusing and a bad experience for the users before we wasted weeks building something that ended up being confusing and frustrating for the people who actually used it.
I’ve also really fouled things up with databases. I once took down production by making a data model change that had run fine in test. Turns out things run differently when a) there’s actual load on the database, and b) there are orders of magnitude more rows in prod than in test. Now I know not to try to make data model changes in mysql cluster without taking the app down for maintenance.
Sadly, that’s not the only time a difference between prod and test has tripped me up. The amount of data in your database can change the way mysql optimizes its queries, which can lead to some really interesting results when you assume the database is using an index that it’s actually blissfully ignoring. And by interesting I mean unusably slow response times. Wheee.
What that one really drove home for me is that you can’t trust the test database unless there’s a full production dump in there and you’re simulating realistic load. Outside of a perfect clone of production, load included, you need to lean on explain plans. Explain plans are great because they tell you how things are going to run into production without actually migrating your whole application to prod and breaking everything. Next time, I’m running explain plans first in production instead of assuming things will be fine because it worked in a test database with a few hundred rows.
Another really entertaining screw up I’ve had was when we were preparing to turn off an online game that wasn’t performing well and was a maintenance nightmare on top of that. We thought that it would be a nice gesture to make the virtual game cards (kind of like a virtual scratch ticket) in the game free so they could play as much as they wanted until we turned the game off entirely. The design of the game didn’t allow us to make the cards entirely free, but it did allow us to make everything cost only one token. Normally higher level game cards cost hundreds of tokens, so we figured players were still getting a pretty good deal.
Unfortunately, I didn’t think through the consequences of players being able to buy hundreds more game cards than usual. On each card you could win credits (thankfully you couldn’t buy more cards with those credits or we really would have been in trouble) that you could use to buy prizes in the store. Normally the number of credits you could possibly win at one time was limited by how many cards you could afford, with the higher level ones that gave out lots of credits being so expensive that you could only buy a few at a time.
Does anyone see where this is going? Yes, overflows! We let players win so many credits that the fields in the database couldn’t hold their winnings. Once we fixed the database we discovered that parts of the game server code couldn’t handle those numbers either. It was a rough few days trying to get that game back into action.
There are two main things I learned from that experience, one specific to the problems we had and one less so.
One – do not make sweeping changes to a game’s economy! Just don’t do it, it’s a bad idea and will make you unhappy. The next time we sunsetted a game (the industry’s polite euphemism for killing it) we most certainly did not destroy the economy on the way out.
Two – the consequences of an action aren’t always obvious, you’ve got to put some work into figuring out what’s going to happen when you change things. If I had that particular change to do over again, I would look at how many daily tokens our top players were getting and calculate how many game cards they could buy with those tokens and how many credits they could win off of those game cards. Then I would try manually giving myself that many credits and tokens in test and see what happens. After watching everything blow up, I would go back to the product manager and say “1 credit game cards break the game, how about we just give players 50% off?”
Let’s mix things up a little. I have one more failure to talk about, but this time it’s not one of mine. Here’s the notification I got about a sad little troll trying to comment on my Shitty hackathon! post:
New comment on your post “Shitty hackathon!”
Date: 10 February, 2016 11:43
Author: Nancy Grace (IP: 72.39.146.43, d72-39-146-43.home1.cgocable.net)
Email: toolofoppression@gmail.com
URL:
Comment: I must say, that I am impressed. Keep it up, and one day you just might earn your official script kiddie participation award. In the meantime, don’t quit your night prostitution job just yet ;)
Now, it’s pretty clear that this shitheap is unable to learn (if he was, he would be good enough at his job not to be frightened of a woman talking about code), but other readers can learn something from this. First of all, it’s pretty clear that he’s terrified of women developers. That in turn makes it obvious he sucks at his job, because with the shortage of developers you have to be a serious fuckup to be afraid a girl will come and steal your job. It’s also pretty sad that he had to go digging three pages back from my front page. Poor bastard had to go past two of my posts about SOLIDdesign principles and my post about Java synchronization and my post about different languages being good for different things before he found something that he thought he could smear his poop on like the shitty little baby he is.
If you’re going to try to shit on me for not being a perfect programmer, get it right! I’m embarrassed for you and I don’t even like you, fuckstick.
However, fuckstick does accidentally bring up something in the vague (astronomically vague) vicinity of a point: if you talk openly about your failures, it’s possible someone will give you shit for having the unbelievable gall to be a human instead of a robot. You should ignore those people because they’re stupid :) No seriously, you do not want to work with or for anyone who is so willfully ignorant of what software development actually is that they think it’s possible to do this without ever making mistakes. If god forbid your boss shows you that they know that little about development, they’ve given you the gift of complete certainty that you need to run. Everybody in Victoria is hiring right now and developers are in demand all over, there’s no reason to put up with a boss who doesn’t understand their industry.
Another reason to talk openly about your failures, especially on your blog, is that when the classic interview question comes up, you’ll have something to say already lined up. You could even share a link to your blog post if you’re less of a potty mouth than I am :)
How about you, readers? What have you screwed up and what did you learn?
A common worry I see in self-taught developers is that not having a degree means that you’re not a good programmer and no one will hire you. I’m not going to lie, having a degree does make it easier to get an interview, but it in no way guarantees that everyone with a degree is a better programmer than everyone without.
Here’s a fun fact about hiring developers: having a degree tells interviewers so little about whether you can code that people came up with the idea of asking candidates to code a very, very simple math “game” called fizzbuzz to figure out if you can write a for loop all by yourself. I’m completely serious, in the mid-late 2000’s fizzbuzz wasall over theprogrammer blogosphere. If you poke around online you will likely find a bunch of criticism about how fizzbuzz is too simple to tell you anything interesting about a junior programmer candidate, which I think is true but is not the point of this post.
Back at my point, it sounds completely ridiculous that you would need to ask a new college/university grad to prove they can write a for loop and a couple of conditionals. How could someone graduate and not be able to code? That question really deserves its own blog post, but part of it is that memorizing facts for a test is a very different skill than writing code on the spot to solve a problem.
Ridiculous or not, people started asking developers to code fizzbuzz for a reason and it’s not because hiring without it worked so well. Fizzbuzz exists as a programming concept because interviewers needed a quick way to weed out people who simply couldn’t program at all.
If you don’t have a degree, don’t feel bad. If you can program at all, then you’re already ahead of the game. You’re probably just as good a coder as anyone who does have one. In a lot of ways being self-taught is more impressive because once you make the decision to go to college/university you’re essentially locked in. Aside from feeling like you have to get your money’s worth once you’ve started paying for a degree, there’s a massive amount of social pressure not to drop out and feel like you’ve disappointed your family and friends.
If you study something on your own time, on the other hand, then it’s much easier to just stop when you’re bored or it’s hard or you’d rather go have a pint with some friends. When nobody will know or necessarily care that you stopped, it’s a lot harder to keep going.
To be fair, having a degree/diploma/certificate from a bootcamp/etc does open doors, and you can end up with really frustrating gaps in your knowledge if you’re self-taught. My husband is a sysadmin but he grudgingly does a little bit of programming when he has to (he’s weird and thinks setting up servers is more fun than writing code). Not so long ago I had to tell him about maps/associative arrays/dictionaries because the last programming class he took was in high school and the language they used didn’t have maps. Turns out there was a point to all the time my teachers spent hammering datatypes into our heads in college after all :)
A degree or a diploma doesn’t mean anyone is special or a better programmer than you are. It really just means they had the good luck and inclination to pick up a degree and some ability to follow through, at least when a large amount of money and the prospect of their parents being disappointed is on the line. Who knows, maybe you’ll be the one asking new grads to code fizzbuzz one day.
“Done” is a surprisingly ambiguous word in software development. Back when I was in college I thought an assignment was “done” if it compiled and produced more or less the result I was expecting. Then I got a job in the industry :)
It turns out “it compiles” doesn’t mean much when you need to ship software that handles edge cases correctly and works in more than one browser and doesn’t throw exceptions when it’s used just slightly differently from the way I assumed it would be when I built it.
Another complication is that people use the word “done” to mean a lot of different things. I’ve heard people say “it’s done, I just need to test it” and “it’s done, I just need to integrate it” and “it’s done, it just needs to go through QA” and “it’s done, I just need to fix a couple of bugs.” It’s certainly useful to know what stage of development a feature is in, but none of those are done.
To me the only meaningful definition of “done” is “ready for production.” That is, is when the developer has tested the feature, QA has passed it, it’s been merged onto the production branch and any regression testing that needed to happen is done. When it’s ready to be deployed it’s done and not before.
That may seem overly picky but imagine how far off the rails things go when one person thinks done means “ready for QA” and someone else on the team thinks done means “ready for production.” If your feature (or project or report) isn’t actually done, your team lead needs to know that whatever other task they give you might get bumped if your original task comes back from QA with bugs. Obviously you should aim for bug free features but in reality things don’t always go according to plan. That’s why we have a QA department in the first place.
And to go on a bit of a rant, that example above of “it’s done, I just need to integrate it” is not even slightly done and is almost always a terrible idea. If you’ve developed something outside of the system it’s going to be a part of, you’ve exposed yourself to an enormous risk of terrible surprises. Sure, you’ll be fine if you just happen to have a perfect understanding of every little quirk of the larger system, but let’s be honest; you do not. Unless it takes a truly intolerable amount of time to compile the main system, you will actually save time in the long run by building your feature directly where it’s going to be used and just getting up for a drink of water or something while your project compiles. You’re almost guaranteed to have to compile repeatedly while you get your feature integrated anyway, so you’re really not saving any time by developing in isolation. Now, the plural of anecdote is not data and other people have probably had different experiences, but I have personally never seen that turn out well and strongly advise against it. Okay, rant over.
We like to pretend software development is perfectly logical and unambiguous, but you’ll actually run into issues like different definitions of done all the time. Even if you feel dumb doing it, it’s often really helpful to ask teammates exactly what they mean. A surprising number of the problems you’ll run into developing software are just miscommunications that could have been cleared up with a five minute conversation at the beginning of the project. Interfaces between client and server code in particular can be tricky. I’ve personally had to throw out work because I misunderstood what the client team actually needed and built something that was pretty close but not quite right.
Just because you think you know what your teammates mean when they say something as simple as “done” doesn’t mean you actually do. I’d love it if we could all agree what done actually means, but until then you can save yourself a lot of trouble by asking questions.
This is a follow up to my post about digital literacy and learning to code. I want to be clear that while I believe everyone should have the opportunity to learn to code and the basics should be taught in school, not everyone has to be a developer or even any good at coding or feel like they need to pour hours and hours into it when they hate it. People seem to get the idea that learn to code initiatives mean everyone! must! learn! to! code! which is not even slightly the case. We just want everyone to be able to make a choice about whether or not they’re interested instead of assuming they’re not welcome.
If you try out, say, a Ladies Learning Code workshop and you come out of it thinking you’d rather have spent the day digging a ditch, great! I started college with a few people who went to all the trouble of applying, getting into the program, and going to class for weeks or months before deciding it wasn’t for them. If you can skip all that hassle and find out in a single day and a measly $50 that code isn’t for you, that’s honestly fantastic. Now you can focus on something you actually like doing instead of something that makes you miserable.
Before you decide code is definitely not your thing, I do have some advice. First of all, learning to code is hard. You’re learning a whole different way of thinking, it takes time to get good at that. Don’t feel bad if you’re not good at it right away. People have different learning styles too. Plenty of my classmates disagreed about which teacher’s explanation of a given concept was clearer. If coding just doesn’t make sense to you, it could be because your teacher isn’t explaining things in a way that makes sense to you.
Or maybe you’re just not in a good headspace to learn a really intense new skill right now. Honestly, if you’re a new parent I don’t recommend trying to force yourself to learn to code. Looking after a tiny human is quite enough stress to put on yourself. If you’re excited about code by all means give it a shot, but if you feel stupid all the time it’s absolutely not because you are stupid, it’s because you’re brutally sleep deprived and stressed out and operating at a huge handicap. Code can wait until you start sleeping regularly again.
All that said, if you understand code just fine but you’d rather watch paint dry, or don’t understand code and would still rather watch paint dry, go do something you actually like! Code is not the only worthwhile thing you can do. Have you ever seen an interface a programmer designed? It was awful, wasn’t it. If you like tech but not programming, you could be a UI designer, an artist, a marketer, a community manager, a tester, a customer service rep, a graphic designer, a copy writer, an admin, a game designer (the easiest way to get to design games is to build your own but that’s not the only way), an animator, an office manager, a level designer, the list goes on and on and on.
If you want to code, great! If you would rather do anything else, great! Don’t ever feel like programming is something you have to do whether you like it or not.
I’m shy, awkward around people I don’t know well, and honestly kind of a dork. So how is that I got three of the four jobs I’ve had since college by knowing people? I show up. That’s seriously it. Physically show up to events, make a minimal effort to be friendly, and you will get to know people who will either introduce you to someone who will offer you a job or offer you a job directly.
So let’s get into details. When I say “events” what am I actually talking about? User groups, code camps, meetups, developer get-togethers, conferences, etc. Victoria is not a large city and we still have a wealth of meetups, your city almost certainly has some too. Google is your friend here, as is twitter and other social media. I found out about whiskydev because a friend tweeted about it. At whiskydev I met a friend who introduced me to my new boss, and now I work at an awesome startup.
If you’re particularly shy, I recommend user groups or meetups where someone gives a talk. How do you know the group is having someone give a talk? They’ll usually announce the speaker and topic ahead of time because they’re excited about having an actual speaker (depending on the group’s topic, it can be a huge pain to find someone to speak so organizers are usually pretty stoked about finding someone) and so that people who either don’t care about or love that topic can make plans accordingly. Talks are easier for shy people because a) you can spend most of your time at the meeting quietly taking notes, and b) afterwards you can ask people how they liked the talk instead of agonizing over how to start a conversation. Not that I’ve ever done that.
Another tip for shy people or for people who are really serious about networking is to volunteer. I volunteer with a number of organizations and I speak from experience when I say there is no such thing as too many volunteers. Come early and help set up, stay late and help clean up, or ask the organizers if they need volunteers for anything. The answer will almost certainly be yes, and now you’ll have a defined job to do which makes it way easier to talk to people.
It’s great if you can be friendly and talk to people, but the first step is just physically showing up. Start there and you’ll be fine.
But to be fair, I have to mention that it is possible for showing up to backfire horribly. If you show up and act like an asshole, word will spread. Victoria in particular is a very small town when it comes to tech. The person you’re a jerk to today could easily be friends with the team lead who’ll be interviewing you tomorrow. On the upside, you kind of have to work at it to be enough of a jerk that someone would tell a friend not to hire you. People are generally pretty forgiving and we all know what it’s like to put our foot in our mouths. Just don’t be a dick and you’ll be fine. That doesn’t mean you can’t have opinions, just that you should phrase them as opinions. For example “I hate working with javascript” is just an opinion, but “javascript sucks and only shitty programmers use it” is going to make you look like a jerk.
And one more tip, particularly for students: class counts as networking. Your professors have probably had students before you, and certainly know people in the industry. Those former students may be the ones interviewing you or asking your professor about you. People your former classmates work with might also ask them what you were like as a classmate. Think about what you want them to say before you show up late and blow off assignments. This applies to your current job as well – just like you aren’t going to stay in one place for your entire career, neither are your coworkers. If you interview somewhere a former coworker now works, what are they going to say about you if the interviewer asks them?
To summarize, my tips for networking are:
Show up
Try to be friendly
Don’t be a dick
For extra credit, volunteer
That’s all you need to do to make contacts who might one day help you find a job. “Networking” can sound like something only slimy salesdroids do, but it’s really just showing up and trying to be friendly.
