I probably suck at my job.
July 19, 2012 8:13 PM Subscribe
I'm a programming intern. I probably suck at my job. My boss hasn't noticed yet. How can I get better before it blows up in my face?
22, female. I graduated in May with a BA in political science, because I discovered my interest in programming junior year, too late to switch to computer science. I didn't even minor in CS, but I took a few classes. Regardless, I have a wonderful internship doing mobile app development because of a family connection.
The internship is seriously awesome and I know I'm lucky as hell to have it. I've been there for about a month now. My boss (who's a programmer) has looked at my progress on the app and told me I'm doing a great job. But I really don't think I am. He's primarily looked at WHAT I've built, not HOW I've built it. I think because he knows how I got the job, he's just pleasantly surprised that I know how to turn on a computer.
My source code is a buggy, disorganized mess, and I don't know how to fix that. Most of my previous experience is in web development, just building very simple database-driven sites and cute little jQuery widgets that don't require any serious organization. I've read all about MVC, and think I basically get the concept, but I've never used it before and I can't figure out how to apply it to this Android project. Internet tutorials haven't helped because they haven't actually spoonfed me a solution. I've sat for hours trying to design a reorganization, but without success. Then I go back to adding features instead, because I'd basically have to redo the whole project, lose most of my progress, and probably still do it wrong.
It's sort of confirming for me that maybe I'm not such an awesome programmer. I mean, I write some of my own code, but so often I've just glued together pieces of other people's code, sometimes without significantly modifying it or even fully understanding it. It's just that this is the first time it hasn't worked.
I don't quite feel like a fraud because I never misrepresented my qualifications (or lack thereof), but I don't feel like I'm overcoming the learning curve fast enough. I've been reading tech books, internet tutorials, etc... of course it's helped some (how else would I have even made my crap app?), but not nearly as much as I'd hoped. I still don't know what I'm doing, and I'm the only person working on this app.
I really, REALLY want to be good at this job. The work environment is great, and the work itself is interesting even though it hurts my brain.
Any advice on being less of a hack? All-purpose learning-curve-conquering wisdom welcome—I know I gave a lot of (perhaps unnecessary) specifics, but my real question is more general: how do you deal with feeling completely out of your depth?
(The internship pays enough that I could afford a studio in a relatively safe area, but I still live with my parents because I'm terrified that I'll sign a lease and then get fired. Jesus, would I ever like to move out.)
22, female. I graduated in May with a BA in political science, because I discovered my interest in programming junior year, too late to switch to computer science. I didn't even minor in CS, but I took a few classes. Regardless, I have a wonderful internship doing mobile app development because of a family connection.
The internship is seriously awesome and I know I'm lucky as hell to have it. I've been there for about a month now. My boss (who's a programmer) has looked at my progress on the app and told me I'm doing a great job. But I really don't think I am. He's primarily looked at WHAT I've built, not HOW I've built it. I think because he knows how I got the job, he's just pleasantly surprised that I know how to turn on a computer.
My source code is a buggy, disorganized mess, and I don't know how to fix that. Most of my previous experience is in web development, just building very simple database-driven sites and cute little jQuery widgets that don't require any serious organization. I've read all about MVC, and think I basically get the concept, but I've never used it before and I can't figure out how to apply it to this Android project. Internet tutorials haven't helped because they haven't actually spoonfed me a solution. I've sat for hours trying to design a reorganization, but without success. Then I go back to adding features instead, because I'd basically have to redo the whole project, lose most of my progress, and probably still do it wrong.
It's sort of confirming for me that maybe I'm not such an awesome programmer. I mean, I write some of my own code, but so often I've just glued together pieces of other people's code, sometimes without significantly modifying it or even fully understanding it. It's just that this is the first time it hasn't worked.
I don't quite feel like a fraud because I never misrepresented my qualifications (or lack thereof), but I don't feel like I'm overcoming the learning curve fast enough. I've been reading tech books, internet tutorials, etc... of course it's helped some (how else would I have even made my crap app?), but not nearly as much as I'd hoped. I still don't know what I'm doing, and I'm the only person working on this app.
I really, REALLY want to be good at this job. The work environment is great, and the work itself is interesting even though it hurts my brain.
Any advice on being less of a hack? All-purpose learning-curve-conquering wisdom welcome—I know I gave a lot of (perhaps unnecessary) specifics, but my real question is more general: how do you deal with feeling completely out of your depth?
(The internship pays enough that I could afford a studio in a relatively safe area, but I still live with my parents because I'm terrified that I'll sign a lease and then get fired. Jesus, would I ever like to move out.)
Also, if they've hired you as an intern, they probably aren't expecting you to be a fully polished professional programmer. Is there anyone at the job you'd consider a mentor who you could take your code to and ask help with organization and structure?
posted by Blue Jello Elf at 8:22 PM on July 19, 2012 [17 favorites]
posted by Blue Jello Elf at 8:22 PM on July 19, 2012 [17 favorites]
I've trained a few dozen college students in roughly your situation, and several stuck with it and became very, very good professionals. You're probably fine. Yes, your evaluation of your code is probably accurate, but for your evaluation of yourself and what's good enough, trust your mentor. He's probably seen great steaming piles of shitty code go into production plenty of times, and if he says you're doing OK, I'm betting he's right.
posted by Monsieur Caution at 8:26 PM on July 19, 2012 [9 favorites]
posted by Monsieur Caution at 8:26 PM on July 19, 2012 [9 favorites]
I've managed undergrads on programming jobs over the past few years and I can safely say that I would be pretty pleased to have an intern who:
That said, you do have thousands of hours of work in front of you to be an amazing programmer. There's nothing anyone can really tell you that's going to make this (or any other profession) particularly easy. But I'd take someone who knows their weaknesses over a cocky hotshot who thinks their undocumented disaster code smells like roses. This phase you're in now is where everyone starts, and lots of people never leave. If you're in this for the long haul, what's going to get you over this hump is trying to understand the broader conceptual models at work in how projects are organized, how languages work, and the tradeoffs you can make in engineering. Ira Glass has a great quote about being in this phase: "We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know it’s normal and the most important thing you can do is do a lot of work." It's an awful and painful period but it's a stage all self-aware professionals go through.
Be honest with your boss. Try to get him to do more than solve your temporary problems or bugs, but help you think about the broader structural questions. I'm not always a fan of expecting people's jobs to be something that follows them home, but in this case you should really fish around for some side projects to sharpen your skills on. It's okay if you don't finish them, but trying out different frameworks and making structural decisions early in a project and living with them for 10-20 hours will teach you a tremendous amount.
Try to use as few libraries as possible. Limit yourself to the language documentation and don't look up code snippets for everything on Stack Overflow. Work through the details yourself. It's going to be slow, but you'll get there in the end if you stick with it. It's like when you're learning a new language and the teacher bans dictionaries from the classroom. If you're looking everything up you're never going to build a working vocabulary. The same is true here. Libraries and snippets are a great shortcut but you need to get the basics first.
Sorry for the long and potentially daunting answer. But hard work and a good mentor will get you through this I'm sure. Be confident that a desire to learn and a commitment to follow through are worth more than years of classes and you'll do great! Feel free to me-mail me if you have more questions!
posted by heresiarch at 8:29 PM on July 19, 2012 [15 favorites]
- delivered something within the first month that worked, even if was buggy and a disaster internally
- understood that the quality of the internals mattered
- was interested in self-improvement
That said, you do have thousands of hours of work in front of you to be an amazing programmer. There's nothing anyone can really tell you that's going to make this (or any other profession) particularly easy. But I'd take someone who knows their weaknesses over a cocky hotshot who thinks their undocumented disaster code smells like roses. This phase you're in now is where everyone starts, and lots of people never leave. If you're in this for the long haul, what's going to get you over this hump is trying to understand the broader conceptual models at work in how projects are organized, how languages work, and the tradeoffs you can make in engineering. Ira Glass has a great quote about being in this phase: "We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know it’s normal and the most important thing you can do is do a lot of work." It's an awful and painful period but it's a stage all self-aware professionals go through.
Be honest with your boss. Try to get him to do more than solve your temporary problems or bugs, but help you think about the broader structural questions. I'm not always a fan of expecting people's jobs to be something that follows them home, but in this case you should really fish around for some side projects to sharpen your skills on. It's okay if you don't finish them, but trying out different frameworks and making structural decisions early in a project and living with them for 10-20 hours will teach you a tremendous amount.
Try to use as few libraries as possible. Limit yourself to the language documentation and don't look up code snippets for everything on Stack Overflow. Work through the details yourself. It's going to be slow, but you'll get there in the end if you stick with it. It's like when you're learning a new language and the teacher bans dictionaries from the classroom. If you're looking everything up you're never going to build a working vocabulary. The same is true here. Libraries and snippets are a great shortcut but you need to get the basics first.
Sorry for the long and potentially daunting answer. But hard work and a good mentor will get you through this I'm sure. Be confident that a desire to learn and a commitment to follow through are worth more than years of classes and you'll do great! Feel free to me-mail me if you have more questions!
posted by heresiarch at 8:29 PM on July 19, 2012 [15 favorites]
sounds like my first internship...
Read, practice by going through tutorials, and ask for help, but when you ask for help make sure that you have tried something first and be able to describe what you did what didn't work, make sure not to ask a question that can be solved with 5 minutes of googling. Also ask other developers to take a look at some of your code to get some feedback on how to do it better. Most people like to help younger devs out as long as you aren't acting like a know it and and put in the effort to learn.
As to organizing code that is a learning process too. So you can get everything to "work" then go back an organize it later. This can work especially if the scope of the project is small. If it's larger than that get out a pad of paper and draw up some picots to help organize it. Try to put related parts together.if a script or code file does more than on thing try to seperate it out into logical parts.
Programing isn't easy, it combines both a creative problem solving with cranking out semi-related things over and over again. But keep practicing.
posted by benk at 8:30 PM on July 19, 2012 [1 favorite]
Read, practice by going through tutorials, and ask for help, but when you ask for help make sure that you have tried something first and be able to describe what you did what didn't work, make sure not to ask a question that can be solved with 5 minutes of googling. Also ask other developers to take a look at some of your code to get some feedback on how to do it better. Most people like to help younger devs out as long as you aren't acting like a know it and and put in the effort to learn.
As to organizing code that is a learning process too. So you can get everything to "work" then go back an organize it later. This can work especially if the scope of the project is small. If it's larger than that get out a pad of paper and draw up some picots to help organize it. Try to put related parts together.if a script or code file does more than on thing try to seperate it out into logical parts.
Programing isn't easy, it combines both a creative problem solving with cranking out semi-related things over and over again. But keep practicing.
posted by benk at 8:30 PM on July 19, 2012 [1 favorite]
I was recently hired at an IT job that I felt I was certainly under qualified for. It took me a little while to realize that they had hired me not because of the knowledge that I had, but because I had proved I was educable. Being able to learn how to solve the problem was what they were looking for, not some previous knowledge.
The number one thing I can say to help you code-wise is comment the hell out of your code. I know people always say, "ya comments are great," but when I get stuck and lose focus I start by trying to diagram the problem, writing out instructions to myself on how I think the functions work together. Drawing relationships out on paper doesn't hurt either.
posted by KeSetAffinityThread at 8:31 PM on July 19, 2012 [4 favorites]
The number one thing I can say to help you code-wise is comment the hell out of your code. I know people always say, "ya comments are great," but when I get stuck and lose focus I start by trying to diagram the problem, writing out instructions to myself on how I think the functions work together. Drawing relationships out on paper doesn't hurt either.
posted by KeSetAffinityThread at 8:31 PM on July 19, 2012 [4 favorites]
Also, what is the mobile platform IOS, Android, mobile web app using html and javascript or something else?
posted by benk at 8:32 PM on July 19, 2012
posted by benk at 8:32 PM on July 19, 2012
My big tip: comment your code! Not only is it the professionally courteous thing to do, it will actually be extremely helpful in helping you become an organized and efficient developer. Just say what you're doing with the code -- put it right in there -- and you will find it a tremendous aid in learning to improve.
posted by trip and a half at 8:33 PM on July 19, 2012 [2 favorites]
posted by trip and a half at 8:33 PM on July 19, 2012 [2 favorites]
You are an intern, so the whole idea of you being there, is that you have the opportunity to learn from professionals. Ask for help! Go to someone friendly - your boss, or another developer, and tell them that you think your code is really disorganized and you need help. Ask for a code review! This is what internships are for! Demonstrating that you are willing and eager to learn, and that you can see areas where you need to improve, puts you leagues ahead of lots of interns.
posted by Joh at 8:39 PM on July 19, 2012 [2 favorites]
posted by Joh at 8:39 PM on July 19, 2012 [2 favorites]
You're an intern. Are they even paying you? Are they even educating you about their dev process and in-house best practices? Is there a QA team to check your work?
Don't worry about it.
At least now you know what you didn't know before.
posted by KokuRyu at 8:42 PM on July 19, 2012 [1 favorite]
Don't worry about it.
At least now you know what you didn't know before.
posted by KokuRyu at 8:42 PM on July 19, 2012 [1 favorite]
We have an intern right now, who's just not cut out to do this kind of work. She's the only intern I've met like this in 4 years, which means she's 1 in probably 30. If your boss tells you you're doing a good job, trust him - you don't have enough experience to really evaluate your own work.
That said, most internships are only as useful as the intern - your education is largely up to you. Work extra hours, volunteer for things you find interesting, ask as many questions as you can, take your boss out to lunch or drinks and pick his/her brain.
posted by OrangeDrink at 8:42 PM on July 19, 2012
That said, most internships are only as useful as the intern - your education is largely up to you. Work extra hours, volunteer for things you find interesting, ask as many questions as you can, take your boss out to lunch or drinks and pick his/her brain.
posted by OrangeDrink at 8:42 PM on July 19, 2012
I suspect that your problem is two-fold; first, you may indeed be somewhat out of your depth in this position, as many interns are. That's kind of the point. They didn't hire you to be a full-fledged employee, they hired you so you could do some work for them, you could learn, and, most importantly, they could evaluate how you learn. In terms of the actual nuts and bolts, I'm sure the programmers, coders, and other computer-literate mefites can help.
The second issue is perhaps more troubling. It sounds like you might have a wee bit of "imposter syndrome." You mention that you feel you only got the job through a connection, that your boss is probably just glad you can turn on a computer, that you aren't moving out due to fear of being imminently fired... that's a lot of anxiety to be carrying around, especially in the face of evidence to the contrary: you haven't been fired, you aren't on constant coffee duty, your boss told you that you are doing a "great job." Those things are meaningful!
There isn't a simple fix for those feelings, but there are things you can do to mitigate the effects. Consistently ask your supervisor for feedback, making it clear that you're not looking for an ego boost but rather concrete, constructive evaluation of your work. Own your mistakes. There's something incredibly empowering in going to your supervisor and saying, "boss, this didn't go well. How can I do it better next time?" It shows maturity, integrity, self-awareness, a truly humble eagerness to learn and improve, and, maybe surprisingly, a lot of self-confidence. Self-confident people are not afraid of their honest mistakes. At the same time, have pride in your accomplishments, and don't be afraid to be open about that pride. You can do a lot! You do have skills. Don't let your fear hold you back.
posted by charmcityblues at 8:44 PM on July 19, 2012 [12 favorites]
The second issue is perhaps more troubling. It sounds like you might have a wee bit of "imposter syndrome." You mention that you feel you only got the job through a connection, that your boss is probably just glad you can turn on a computer, that you aren't moving out due to fear of being imminently fired... that's a lot of anxiety to be carrying around, especially in the face of evidence to the contrary: you haven't been fired, you aren't on constant coffee duty, your boss told you that you are doing a "great job." Those things are meaningful!
There isn't a simple fix for those feelings, but there are things you can do to mitigate the effects. Consistently ask your supervisor for feedback, making it clear that you're not looking for an ego boost but rather concrete, constructive evaluation of your work. Own your mistakes. There's something incredibly empowering in going to your supervisor and saying, "boss, this didn't go well. How can I do it better next time?" It shows maturity, integrity, self-awareness, a truly humble eagerness to learn and improve, and, maybe surprisingly, a lot of self-confidence. Self-confident people are not afraid of their honest mistakes. At the same time, have pride in your accomplishments, and don't be afraid to be open about that pride. You can do a lot! You do have skills. Don't let your fear hold you back.
posted by charmcityblues at 8:44 PM on July 19, 2012 [12 favorites]
I've programmed and managed programmers for over 10 years, I've just started to feel somewhat secure in my code in the past few years. It takes *a lot* of practice for most, if not all, people. Only a few people can be some sort of coding natural, yet there are millions of professional programmers. What I am saying is that I think you may be holding yourself to unrealisticaly high standards, you are an intern, not a lead developer.
Since you are an intern, you should ask your boss for some mentorship. I have junior devs ask me for input on everything from architecture to specifics of code structure all the time. One thing nerds, and professionals of all stripes, love to do is show off.
As for bugs, you guys are a team, you have testers to test no? No one person can do everything themselves.
I wrote This for high level "management" of development, you will need to learn how to manage releases eventually and looking into DI, testing, design patterns may help you now.
The main thing to learn now is proper encapsulation and separation of concerns. I force this on everyone I work with. If you need to access a datastore, don't just add DB access all over your source. Plan ahead for an "interface" that your data access "module" will provide. This will help you in several ways. You can write mockups , where you just hand back mock data without hitting the DB so you can test your design and theories. All the DB "gunk" will be in one place , where you can change it all if need be. You can automate testing, sure that all your like code will be excercised, and you wont miss some DB code somewhere else. Lastly, if they decide to change specs on you, you can rewrite entire portions while leaving DB access alone, or switch from SQL to a key-value store without touching your logic.
Likewise, code that touches the filesystem should be encapsulated, code that uses web services should be encapsulated, etc.
This will help keep code clean, and when you need to go back and change something like a DB schema, you won't be changing code all over your app.
Log fucking everything. When your code is in production your comments won't help you.
I am peculiar, I like compile time errors. For this reason I hate Regex, SQL, and dynamic typing. I want to see all my type errors now, not at runtime.
If you do UI, pay attention to UX. This means no stuff like locking the UI while you crunch data. Customers don't care about how nice the code is, they care that the app is responsive and looks professional.
posted by Ad hominem at 8:44 PM on July 19, 2012 [3 favorites]
Since you are an intern, you should ask your boss for some mentorship. I have junior devs ask me for input on everything from architecture to specifics of code structure all the time. One thing nerds, and professionals of all stripes, love to do is show off.
As for bugs, you guys are a team, you have testers to test no? No one person can do everything themselves.
I wrote This for high level "management" of development, you will need to learn how to manage releases eventually and looking into DI, testing, design patterns may help you now.
The main thing to learn now is proper encapsulation and separation of concerns. I force this on everyone I work with. If you need to access a datastore, don't just add DB access all over your source. Plan ahead for an "interface" that your data access "module" will provide. This will help you in several ways. You can write mockups , where you just hand back mock data without hitting the DB so you can test your design and theories. All the DB "gunk" will be in one place , where you can change it all if need be. You can automate testing, sure that all your like code will be excercised, and you wont miss some DB code somewhere else. Lastly, if they decide to change specs on you, you can rewrite entire portions while leaving DB access alone, or switch from SQL to a key-value store without touching your logic.
Likewise, code that touches the filesystem should be encapsulated, code that uses web services should be encapsulated, etc.
This will help keep code clean, and when you need to go back and change something like a DB schema, you won't be changing code all over your app.
Log fucking everything. When your code is in production your comments won't help you.
I am peculiar, I like compile time errors. For this reason I hate Regex, SQL, and dynamic typing. I want to see all my type errors now, not at runtime.
If you do UI, pay attention to UX. This means no stuff like locking the UI while you crunch data. Customers don't care about how nice the code is, they care that the app is responsive and looks professional.
posted by Ad hominem at 8:44 PM on July 19, 2012 [3 favorites]
Definitely ask for a mentor(s) who can give you code reviews. Programming-wise I learned the most on the job from code reviews given by people who were good at giving feedback.
As you continue in your successful career, if you still find yourself feeling like a fraud who doesn't belong, read up on Imposter Syndrome and don't let yourself get stuck in it! Here's a Caltech write-up on it: http://www.counseling.caltech.edu/InfoandResources/Impostor
posted by girlhacker at 8:44 PM on July 19, 2012 [3 favorites]
As you continue in your successful career, if you still find yourself feeling like a fraud who doesn't belong, read up on Imposter Syndrome and don't let yourself get stuck in it! Here's a Caltech write-up on it: http://www.counseling.caltech.edu/InfoandResources/Impostor
posted by girlhacker at 8:44 PM on July 19, 2012 [3 favorites]
Whoa. Hold on there.
This is an internship. The whole point is that you're learning. You don't even have a full CS degree and you're producing passable code that runs and does what you want it to? That's huge. So feel damn good about yourself, for starters. For another:
You say your boss looks at what your code does, not how it does it. Well, okay, so ask about that! "Hey, I'm having trouble with X." Or "Hey, I found this solution to Y, can you help me understand what it's really doing?" Or even "So I did Z, and it worked, but it feels ugly as hell, can you give me some tips on how to make it smoother?"
You're an intern. You're there to learn. So long as you're producing code that runs and does its job, let me assure you, you're doing great. Recognize that you're in Learning Mode and not just Production Mode; be totally unabashed about asking questions. I've been writing code professionally for 5 years on top of a CS degree, and I can tell you that I asked a ton of questions when I started out, and my opinion of novice developers is almost always more based on how curious they are and how eager they are to improve and learn, rather than how good they might be right out of the gate.
posted by Tomorrowful at 8:45 PM on July 19, 2012 [10 favorites]
This is an internship. The whole point is that you're learning. You don't even have a full CS degree and you're producing passable code that runs and does what you want it to? That's huge. So feel damn good about yourself, for starters. For another:
You say your boss looks at what your code does, not how it does it. Well, okay, so ask about that! "Hey, I'm having trouble with X." Or "Hey, I found this solution to Y, can you help me understand what it's really doing?" Or even "So I did Z, and it worked, but it feels ugly as hell, can you give me some tips on how to make it smoother?"
You're an intern. You're there to learn. So long as you're producing code that runs and does its job, let me assure you, you're doing great. Recognize that you're in Learning Mode and not just Production Mode; be totally unabashed about asking questions. I've been writing code professionally for 5 years on top of a CS degree, and I can tell you that I asked a ton of questions when I started out, and my opinion of novice developers is almost always more based on how curious they are and how eager they are to improve and learn, rather than how good they might be right out of the gate.
posted by Tomorrowful at 8:45 PM on July 19, 2012 [10 favorites]
Knowing your code sucks is the first step. I keep around a huge repository of things I've written so I can remind myself I am not so smart.
The second step is WHY does your code suck. Forget about buzzwords for a minute and just think, what don't I like about this? Is there too much code duplication? Too many obscure functions with weird default arguments? Too slow? Too byzantine? Try to think of a way to approach it that would be simpler.
Refactoring has to go in stages. You make a slightly simpler version that still works, and then a slightly simpler version that still works. You take out what you don't need, consolidate.
Don't prematurely optimize - take reasonably easy paths until it becomes clear that you need something better. Don't write functions you don't need, or interfaces you don't need.
Learn from people better than you, get them to look at your code. Exposing your awfulness is hard, swallow your pride and accept what people say. Don't apologize for first drafts, just get it done and make it better.
posted by RustyBrooks at 8:45 PM on July 19, 2012 [3 favorites]
The second step is WHY does your code suck. Forget about buzzwords for a minute and just think, what don't I like about this? Is there too much code duplication? Too many obscure functions with weird default arguments? Too slow? Too byzantine? Try to think of a way to approach it that would be simpler.
Refactoring has to go in stages. You make a slightly simpler version that still works, and then a slightly simpler version that still works. You take out what you don't need, consolidate.
Don't prematurely optimize - take reasonably easy paths until it becomes clear that you need something better. Don't write functions you don't need, or interfaces you don't need.
Learn from people better than you, get them to look at your code. Exposing your awfulness is hard, swallow your pride and accept what people say. Don't apologize for first drafts, just get it done and make it better.
posted by RustyBrooks at 8:45 PM on July 19, 2012 [3 favorites]
I think it is great you are being proactive and taking positive steps. I'll just add that I have experience supervising grads from top 10 CS programs and "buggy, disorganized mess" is exactly how I would describe the code of most of them after a month. So it's not that CS students have a skill you lack—it's something everyone has to learn.
Follow the suggestions other people give you here and you'll do great!
posted by grouse at 9:03 PM on July 19, 2012 [1 favorite]
Follow the suggestions other people give you here and you'll do great!
posted by grouse at 9:03 PM on July 19, 2012 [1 favorite]
Have you ever heard of the Fizz Buzz Test? You can pass it, and that puts you ahead of tons of other 'programmers' out there.
That said, to address your question, I'd add that you should also try reading other people's code. Read your supervisor's code that's being checked into your source code repository, read open source code, read whatever you can get your hands on. You can get an idea of how more experienced programmers write code; you will see some examples of what not to do (if you're lucky you may also run across some truly ridiculous code which has been commented wryly on by some other coder who happened across it before you). You will see what patterns are employed where (MVC is easy to spot, objects are almost always called BlahModel, BlahView, BlahController). Try to find examples where problems you yourself have had to solve before are tackled differently: Decide whether your approach was better or worse (don't assume it was worse! Cargo cult programming is a bad habit).
posted by axiom at 9:20 PM on July 19, 2012
That said, to address your question, I'd add that you should also try reading other people's code. Read your supervisor's code that's being checked into your source code repository, read open source code, read whatever you can get your hands on. You can get an idea of how more experienced programmers write code; you will see some examples of what not to do (if you're lucky you may also run across some truly ridiculous code which has been commented wryly on by some other coder who happened across it before you). You will see what patterns are employed where (MVC is easy to spot, objects are almost always called BlahModel, BlahView, BlahController). Try to find examples where problems you yourself have had to solve before are tackled differently: Decide whether your approach was better or worse (don't assume it was worse! Cargo cult programming is a bad habit).
posted by axiom at 9:20 PM on July 19, 2012
You feel out of our depth...to me, this points out that you don't have connections to other's who are also learning.
You should try out the Grace Hopper Women in Computing conference. Loads of smart women involved in tech, from students to industry. There are academic talks, industry talks, career and educational talks, and loads of social opportunities (and a job fair).
I'm from a humanities background, and sort of landed in a development track. This conference was helpful in that I got to meet and see other women who were in tech. They all had a variety of skillsets. I went by myself and randomly made friends. I got super excited, because this showed me that there are so many women who are into programming, development, testing, whatever...and they will help you. No matter your skillset. If you're starting out, it's really helpful to know there are many others, just like you, learning and stumbling.
http://gracehopper.org/2012/participate/hoppers/ Link to volunteer at the conference (you pay travel and lodging). It's in Baltimore, early October.
If you end up going, pm me.
posted by shinyshiny at 9:23 PM on July 19, 2012 [5 favorites]
You should try out the Grace Hopper Women in Computing conference. Loads of smart women involved in tech, from students to industry. There are academic talks, industry talks, career and educational talks, and loads of social opportunities (and a job fair).
I'm from a humanities background, and sort of landed in a development track. This conference was helpful in that I got to meet and see other women who were in tech. They all had a variety of skillsets. I went by myself and randomly made friends. I got super excited, because this showed me that there are so many women who are into programming, development, testing, whatever...and they will help you. No matter your skillset. If you're starting out, it's really helpful to know there are many others, just like you, learning and stumbling.
http://gracehopper.org/2012/participate/hoppers/ Link to volunteer at the conference (you pay travel and lodging). It's in Baltimore, early October.
If you end up going, pm me.
posted by shinyshiny at 9:23 PM on July 19, 2012 [5 favorites]
Supposedly, the most reliable way to learn good code organization is an intensive four-year degree program which requires working on large projects and focusing on software structure. Realistically... Sometimes that works, sometimes it doesn't. Even if you have a good coder, pressures of a production environment (deadlines, performance, whatever) can result in pretty awful stuff. Honestly, you're probably doing fine.
One good principle for organizing things is to make things modular and test it - get a piece of paper and think of your program as a couple of blobs that talk to each other. If one of the blobs goes away or gets replaced, can the others still keep sending messages? Can you write tests to prove that they do?
For a complete guide to reworking messy code, you can check out Working Effectively with Legacy Code - many people at my company have a copy on their desks (I try not to think too hard about that). One useful technique from it is the Sprout Method, which is just a specific way of making existing components manageable.
posted by 23 at 9:31 PM on July 19, 2012 [1 favorite]
One good principle for organizing things is to make things modular and test it - get a piece of paper and think of your program as a couple of blobs that talk to each other. If one of the blobs goes away or gets replaced, can the others still keep sending messages? Can you write tests to prove that they do?
For a complete guide to reworking messy code, you can check out Working Effectively with Legacy Code - many people at my company have a copy on their desks (I try not to think too hard about that). One useful technique from it is the Sprout Method, which is just a specific way of making existing components manageable.
posted by 23 at 9:31 PM on July 19, 2012 [1 favorite]
+1 everything everybody else has said. It takes *years* to get good at anything. The whole point of the internship is that you're learning. If anything, by providing you with experience and the direction for areas you want improvement in, you're getting *exactly* what you should be getting out of this experience.
After you read Code Complete, which has been recommend above, go ahead and read everything Joel has written.
Then work for a decade.
You'll be fine :)
posted by colin_l at 9:46 PM on July 19, 2012 [1 favorite]
After you read Code Complete, which has been recommend above, go ahead and read everything Joel has written.
Then work for a decade.
You'll be fine :)
posted by colin_l at 9:46 PM on July 19, 2012 [1 favorite]
Nthing everything everybody else has said about your being there to learn and your present attitude being completely sound.
Remember that good code is what's left over after you've deleted nine tenths of what you wrote.
Also, every working programmer and every project manager should have read The Mythical Man-Month.
Get used to feeling like an impostor. If you don't feel like that at least some of the time, you're doing it wrong.
posted by flabdablet at 10:03 PM on July 19, 2012 [2 favorites]
Remember that good code is what's left over after you've deleted nine tenths of what you wrote.
Also, every working programmer and every project manager should have read The Mythical Man-Month.
Get used to feeling like an impostor. If you don't feel like that at least some of the time, you're doing it wrong.
posted by flabdablet at 10:03 PM on July 19, 2012 [2 favorites]
My source code is a buggy, disorganized mess, and I don't know how to fix that
Learn git and then just start fixing it, one piece at a time. You will likely not be given time to do this at work; most employers simply don't care how bad the code stinks.
posted by flabdablet at 10:11 PM on July 19, 2012
Learn git and then just start fixing it, one piece at a time. You will likely not be given time to do this at work; most employers simply don't care how bad the code stinks.
posted by flabdablet at 10:11 PM on July 19, 2012
To add to what everyone else is saying: working code in a month? Your boss says you're doing fine? Then you're exactly where a good intern is expected to be.
I'm also a woman and it really does sound like a touch of imposter syndrome (supposedly more common for women in tech than for men, but I'm not sure how true that is). I still feel like I'm not "good enough" at times even after a decade in the industry and regular positive reviews, everyone loving me on my teams, etc.
So don't sweat things too much. Practice more and ask for help. Eeryone makes mistakes so no one will think less of you for asking for some guidance -- well no one I would ever want to work with.
posted by R343L at 10:59 PM on July 19, 2012
I'm also a woman and it really does sound like a touch of imposter syndrome (supposedly more common for women in tech than for men, but I'm not sure how true that is). I still feel like I'm not "good enough" at times even after a decade in the industry and regular positive reviews, everyone loving me on my teams, etc.
So don't sweat things too much. Practice more and ask for help. Eeryone makes mistakes so no one will think less of you for asking for some guidance -- well no one I would ever want to work with.
posted by R343L at 10:59 PM on July 19, 2012
You should try out the Grace Hopper Women in Computing conference. Loads of smart women involved in tech, from students to industry. There are academic talks, industry talks, career and educational talks, and loads of social opportunities (and a job fair).
Agreed - I've heard from a few people (one of whom got an amazing job out of it) that the schmoozing and the job fair are very good at Grace Hopper. Those same people also said the talks weren't very interesting, but they agreed that it was absolutely worth it for the networking opportunities.
posted by ripley_ at 10:59 PM on July 19, 2012
Agreed - I've heard from a few people (one of whom got an amazing job out of it) that the schmoozing and the job fair are very good at Grace Hopper. Those same people also said the talks weren't very interesting, but they agreed that it was absolutely worth it for the networking opportunities.
posted by ripley_ at 10:59 PM on July 19, 2012
Another suggestion: find a competent person in your group / company that knows about your work (may be your boss) and approach them with the story you served us. Insist on the 3 points "I made it work somehow, but I really want to do it right, and I see what I have so far does not seem right" then say "can you help?"
If I was a mentor I would gladly help, because by saying this you're making it clear you're worth my time.
posted by knz at 12:46 AM on July 20, 2012 [1 favorite]
If I was a mentor I would gladly help, because by saying this you're making it clear you're worth my time.
posted by knz at 12:46 AM on July 20, 2012 [1 favorite]
Other people will have specific advice so I'll keep it high level.
The first step is recognizing you have a problem. That's actually a huge step. Seriously. You can't get better if you don't recognize bad.
Some general suggestions though: read other peoples code. I don't know about any open source android apps, but our best devs had a great deal of respect for the Postgres code base. Try asking around on StackExchange for some android examples to learn from.
Also, engage your mentor. You are an intern. They may have resented the fact that you got dropped in their lap because of your family connection, but it doesn't sound like you've gotten a bad vibe from them, so it's not an issue now. Tell them you'd like to leave them with robust, maintainable code, and youd like guidance on how to improve. Ask to do a code review.
I'll tell you, we had an intern from CMU (one of the top CS schools) he came to us through a family connection after his Freshman year. He got the job done and improved a lot over the summer, enough so that we offered him a job, but he was still very junior and it took another 3 months or so before people were happy with the code he checked in, and he was getting feedback from senior deva every other day or so.
So, keep at it, you are doing fine, and you will do better with time, effort, and experience. When you do refactor your code, bite it off in small, manageable chunks, but at this point, don't fret if you ultimately end up rewriting a majority of it.
posted by Good Brain at 1:22 AM on July 20, 2012 [1 favorite]
The first step is recognizing you have a problem. That's actually a huge step. Seriously. You can't get better if you don't recognize bad.
Some general suggestions though: read other peoples code. I don't know about any open source android apps, but our best devs had a great deal of respect for the Postgres code base. Try asking around on StackExchange for some android examples to learn from.
Also, engage your mentor. You are an intern. They may have resented the fact that you got dropped in their lap because of your family connection, but it doesn't sound like you've gotten a bad vibe from them, so it's not an issue now. Tell them you'd like to leave them with robust, maintainable code, and youd like guidance on how to improve. Ask to do a code review.
I'll tell you, we had an intern from CMU (one of the top CS schools) he came to us through a family connection after his Freshman year. He got the job done and improved a lot over the summer, enough so that we offered him a job, but he was still very junior and it took another 3 months or so before people were happy with the code he checked in, and he was getting feedback from senior deva every other day or so.
So, keep at it, you are doing fine, and you will do better with time, effort, and experience. When you do refactor your code, bite it off in small, manageable chunks, but at this point, don't fret if you ultimately end up rewriting a majority of it.
posted by Good Brain at 1:22 AM on July 20, 2012 [1 favorite]
Many coders spend the first few years of their careers writing buggy disorganized crap and don't even realize that that's what they're doing.
You are way ahead of the game. Be easier on yourself.
posted by ook at 3:58 AM on July 20, 2012 [4 favorites]
You are way ahead of the game. Be easier on yourself.
posted by ook at 3:58 AM on July 20, 2012 [4 favorites]
Man, android programming is not something that's easy to dive into doing, it's taken me a full year of (admittedly casual) programming just to get what I feel is a really good hold on the broad concepts involved and the necessary nitty gritty details. So don't feel bad, I've been programming for nearly a decade now (professionally for half of that).
Since you're used to web programming, have you thought about using a library like phonegap to leverage your existing knowledge into a mobile app?
And don't feel bad about googling code snippets and solutions to problems you're having. I do it regularly. Under one condition though: really try to understand exactly what your problem is and how your researched solution works.
As far as design goes, look at the example apps and try building a few. I feel this is something you're only going to pick up through practice. There's no silver bullet, unfortunately, so don't waste too much time fretting over that fact. If you're unsatisfied with an aspect of your design then come up with a better way and try it out.
posted by symbollocks at 7:37 AM on July 20, 2012
Since you're used to web programming, have you thought about using a library like phonegap to leverage your existing knowledge into a mobile app?
And don't feel bad about googling code snippets and solutions to problems you're having. I do it regularly. Under one condition though: really try to understand exactly what your problem is and how your researched solution works.
As far as design goes, look at the example apps and try building a few. I feel this is something you're only going to pick up through practice. There's no silver bullet, unfortunately, so don't waste too much time fretting over that fact. If you're unsatisfied with an aspect of your design then come up with a better way and try it out.
posted by symbollocks at 7:37 AM on July 20, 2012
Take a deep breath and realize that is going to be okay. I've been a programming intern and I've mentored interns. It is normal to write sucky code at that level of experience and generally people aren't expecting you be proficient. In my internships the most important things I learned were how to communicate during meetings, behaving like a professional and knowing what to wear in the workplace. I learned some programming stuff too.
posted by dgran at 8:17 AM on July 20, 2012 [1 favorite]
posted by dgran at 8:17 AM on July 20, 2012 [1 favorite]
Agree with everyone who says finding a mentor is a good thing. If there isn't anyone at your job you're comfortable approaching, try contacting a programming professor from college. (Be careful about disclosing company assets though.)
posted by SuperSquirrel at 8:46 AM on July 20, 2012
posted by SuperSquirrel at 8:46 AM on July 20, 2012
"I've read all about MVC, and think I basically get the concept, but I've never used it before and I can't figure out how to apply it to this Android project. Internet tutorials haven't helped because they haven't actually spoonfed me a solution. I've sat for hours trying to design a reorganization, but without success. Then I go back to adding features instead, because I'd basically have to redo the whole project, lose most of my progress, and probably still do it wrong."
Your instincts may be right here: you've got a more-or-less working program, and that's valuable in itself. Throwing it out and trying to redesign it from scratch is risky. Instead, could you make a list of the bugs or ugly, hard-to-understand parts? Then tackle them one at a time. Start with something easy to fix, or something that will simplify adding your next new feature.
Coding is like writing papers: few of us write beautiful well-organized arguments on our first attempt. Instead we write a first draft and then tweak it into readability.
Some tools that help: automated testing. You should be able to press a button, get a bunch of tests run, and get back a simple pass/fail answer. I have no idea how you do that with an android app but I'm sure somebody does; find them.
As said above, learn git if you're not already using some kind of version control. Git can be confusing; expect it to take some time to learn.
The goal is to get from where you are to something better by a series of small incremental steps, testing and committing after each step.
And don't try to solve every problem at once or stop the world until your code is perfect; you can keep adding features and clean things up as you go.
Along with premature optimization there's also some risk of premature abstraction. By all means, learn about MVC and the rest, take advantage of any opportunities to encapsulate pieces of your program where you realize it makes sense, etc. but don't worry too much about whether your code fits the pattern exactly. In your situation there may be a tendency to assume that there are some grand ideas that you're missing that the Real Programmers have, but that's mostly not the case; mostly you probably need some tools and practice.
And as everybody else says, your feelings here are totally normal and not a sign that you're doing anything wrong. Don't let these feelings make you secretive or keep you from asking for help.
posted by bfields at 9:23 AM on July 20, 2012
Your instincts may be right here: you've got a more-or-less working program, and that's valuable in itself. Throwing it out and trying to redesign it from scratch is risky. Instead, could you make a list of the bugs or ugly, hard-to-understand parts? Then tackle them one at a time. Start with something easy to fix, or something that will simplify adding your next new feature.
Coding is like writing papers: few of us write beautiful well-organized arguments on our first attempt. Instead we write a first draft and then tweak it into readability.
Some tools that help: automated testing. You should be able to press a button, get a bunch of tests run, and get back a simple pass/fail answer. I have no idea how you do that with an android app but I'm sure somebody does; find them.
As said above, learn git if you're not already using some kind of version control. Git can be confusing; expect it to take some time to learn.
The goal is to get from where you are to something better by a series of small incremental steps, testing and committing after each step.
And don't try to solve every problem at once or stop the world until your code is perfect; you can keep adding features and clean things up as you go.
Along with premature optimization there's also some risk of premature abstraction. By all means, learn about MVC and the rest, take advantage of any opportunities to encapsulate pieces of your program where you realize it makes sense, etc. but don't worry too much about whether your code fits the pattern exactly. In your situation there may be a tendency to assume that there are some grand ideas that you're missing that the Real Programmers have, but that's mostly not the case; mostly you probably need some tools and practice.
And as everybody else says, your feelings here are totally normal and not a sign that you're doing anything wrong. Don't let these feelings make you secretive or keep you from asking for help.
posted by bfields at 9:23 AM on July 20, 2012
I agree with those who say you're being way too hard on yourself.
In terms of learning how to organize your code, I think the best idea (other than finding a good mentor) is finding a good example of published code that is somehow analogous to yours and seeing how it is put together.
posted by callmejay at 9:57 AM on July 20, 2012
In terms of learning how to organize your code, I think the best idea (other than finding a good mentor) is finding a good example of published code that is somehow analogous to yours and seeing how it is put together.
posted by callmejay at 9:57 AM on July 20, 2012
Congrats on gettings something working!
Ask for code reviews from coworkers and your boss. Do you have some friendly people you work with? outline your code to them and ask how to make it better.
Code reviews, code reviews, code reviews ... formal or informal.
posted by captaincrouton at 11:11 AM on July 20, 2012
Ask for code reviews from coworkers and your boss. Do you have some friendly people you work with? outline your code to them and ask how to make it better.
Code reviews, code reviews, code reviews ... formal or informal.
posted by captaincrouton at 11:11 AM on July 20, 2012
It's a really good sign that you think your current code is bad. Keep re-writing it til it no longer looks that way. That's how you learn. Bad programmers don't know their code is bad and so have no way to improve.
posted by w0mbat at 12:46 PM on July 20, 2012
posted by w0mbat at 12:46 PM on July 20, 2012
Off the top of my head, here are a few red flags when I look at code:
1. Repetition: When I see code with the same text over and over, it is a missed opportunity for simplification. If you code anything more than twice, put it into a function or subroutine. If you ever need to change the code, instead of changing it all over the place, you can change it in once place. If you put commonly used into a function/subroutine, you only need to understand it once. If the code is copy/pasted all over the place, you need to make sure each one isn't different in some way.
2. Warnings. Fix all the warnings. You learn a lot just by understanding and fixing these.
3. Wrong order. Think about the order you doing things. If you're iterating over a collection, then iterating over it again later, try moving things around so you only iterate over the collection once.
Lots more here.
Good luck! Kick butt!
posted by sarah_pdx at 5:48 PM on July 20, 2012 [1 favorite]
1. Repetition: When I see code with the same text over and over, it is a missed opportunity for simplification. If you code anything more than twice, put it into a function or subroutine. If you ever need to change the code, instead of changing it all over the place, you can change it in once place. If you put commonly used into a function/subroutine, you only need to understand it once. If the code is copy/pasted all over the place, you need to make sure each one isn't different in some way.
2. Warnings. Fix all the warnings. You learn a lot just by understanding and fixing these.
3. Wrong order. Think about the order you doing things. If you're iterating over a collection, then iterating over it again later, try moving things around so you only iterate over the collection once.
Lots more here.
Good luck! Kick butt!
posted by sarah_pdx at 5:48 PM on July 20, 2012 [1 favorite]
Hi, I'm a fellow female junior programmer and self-critical perfectionist, and I'm here to tell you that if your boss says you're doing great and yet you feel like you suck, you are holding yourself to impossible standards, full stop.
Others have done a great job of addressing how to handle these anxieties constructively in your code/work, so I'm going to try to address how to manage the anxiety itself.
#1 piece of advice is to let yourself feel them, but don't let them make you give up. View them as an unpleasant but temporary affliction that isn't relevant to your behavior, like the common cold, and wait them out until they fade.
Notice the stress and self-doubt as it occurs and observe its physical manifestations dispassionately. Remind yourself, firmly but with empathy, of all the reasons why you know that the feelings are not accurate markers of truth.
Generate and then constantly remind yourself of alternate explanations for the feelings (other than "I suck"). Some of this will be personal, but please do read about imposter syndrome, cognitive psych research on the unreliability of self-assessment, and gender dynamics in the tech industry. This is absolutely a gendered phenomenon in broader tech culture, so it's probable there are factors in play here that have nothing to do with the quality of your code.
Working on other projects is a an excellent idea, but when I was really new to programming and struggling with self-doubt, it made me want to avoid coding in my free time because I was associating it with nasty anxiety feelings. I broke out of this cycle by a) not beating myself up about having too few external projects (that just feeds the anxiety) and b) working on projects with friends, particularly other women. Working informally with supportive people is motivating, validating, helps you see that no one writes perfect code from scratch all the time, and is FUN!
I really hope you stick it out. It took about 9 months of telling myself I didn't suck before I started believing it, and now I am kicking ass and thrilled with my new career, as I bet you will be too!
MeMail me if you want a supportive ear.
posted by introcosm at 6:31 PM on July 20, 2012 [3 favorites]
Others have done a great job of addressing how to handle these anxieties constructively in your code/work, so I'm going to try to address how to manage the anxiety itself.
#1 piece of advice is to let yourself feel them, but don't let them make you give up. View them as an unpleasant but temporary affliction that isn't relevant to your behavior, like the common cold, and wait them out until they fade.
Notice the stress and self-doubt as it occurs and observe its physical manifestations dispassionately. Remind yourself, firmly but with empathy, of all the reasons why you know that the feelings are not accurate markers of truth.
Generate and then constantly remind yourself of alternate explanations for the feelings (other than "I suck"). Some of this will be personal, but please do read about imposter syndrome, cognitive psych research on the unreliability of self-assessment, and gender dynamics in the tech industry. This is absolutely a gendered phenomenon in broader tech culture, so it's probable there are factors in play here that have nothing to do with the quality of your code.
Working on other projects is a an excellent idea, but when I was really new to programming and struggling with self-doubt, it made me want to avoid coding in my free time because I was associating it with nasty anxiety feelings. I broke out of this cycle by a) not beating myself up about having too few external projects (that just feeds the anxiety) and b) working on projects with friends, particularly other women. Working informally with supportive people is motivating, validating, helps you see that no one writes perfect code from scratch all the time, and is FUN!
I really hope you stick it out. It took about 9 months of telling myself I didn't suck before I started believing it, and now I am kicking ass and thrilled with my new career, as I bet you will be too!
MeMail me if you want a supportive ear.
posted by introcosm at 6:31 PM on July 20, 2012 [3 favorites]
you've got a more-or-less working program, and that's valuable in itself. Throwing it out and trying to redesign it from scratch is risky.
Doesn't stop people from doing it, though.
read other peoples code.
Absolutely excellent idea. Do that.
As well as tracking down code from nearby developers you respect, spend some time each day at The Daily WTF. Read enough of their stuff and you will build yourself a pretty good antipattern detector.
posted by flabdablet at 5:57 AM on July 21, 2012
Doesn't stop people from doing it, though.
read other peoples code.
Absolutely excellent idea. Do that.
As well as tracking down code from nearby developers you respect, spend some time each day at The Daily WTF. Read enough of their stuff and you will build yourself a pretty good antipattern detector.
posted by flabdablet at 5:57 AM on July 21, 2012
when I was taking programming classes, I found that many people were confident and boastful, and I nearly quit because it seemed like I was totally unable to learn it. The I found out many of the confident people had no reason to be confident, and the boasters were especially full of it. Also, many peole were taking the class for the 2nd (3rd) time, including experienced programmers picking up a new language. So you may be doing better thank you think. Women. especially, tend to be less confident in themselves and their work.
Ask for a mentor, or start a group to study each other's code and critique it with the goal of improving. Find sites where people ask others to review their code, and look at other code. Write lots and lots more code. Get together with other women in technology for a monthly/weekly lunch, and share stories and support. Review your own code and make it better. It takes practice, so keep at it. You can do this.
posted by theora55 at 3:34 PM on July 21, 2012 [1 favorite]
Ask for a mentor, or start a group to study each other's code and critique it with the goal of improving. Find sites where people ask others to review their code, and look at other code. Write lots and lots more code. Get together with other women in technology for a monthly/weekly lunch, and share stories and support. Review your own code and make it better. It takes practice, so keep at it. You can do this.
posted by theora55 at 3:34 PM on July 21, 2012 [1 favorite]
BTW, looking back at our comments I realize we may be conveying disdain for any kind of computer science education. There are advantages to taking all those courses. It's just that the particular things you're asking about (how to write well-organized code, etc.) is something people mostly learn on the job. There's a pile of other stuff (data structures and algorithms, computer architecture, operating systems, a little discrete mathematics...) that you can also pick up on the job, but that may be easier to get at school.
(And: I don't know much about computer science programs, but my guess is that a masters program, for example, would be happy to get a good student who proved their enthusiasm in an internship despite not majoring as an undergraduate, and help them figure out a reasonable program of study given that background.)
posted by bfields at 9:26 AM on July 22, 2012
(And: I don't know much about computer science programs, but my guess is that a masters program, for example, would be happy to get a good student who proved their enthusiasm in an internship despite not majoring as an undergraduate, and help them figure out a reasonable program of study given that background.)
posted by bfields at 9:26 AM on July 22, 2012
« Older There may be bugs on some of you mugs... | Congratulations, new priest! (I don't agree with... Newer »
This thread is closed to new comments.
Honestly, it just takes a lot of practice to get to the point where you have solid skills. You do things the hard way a thousand times and then you find out an easy way to do it. Eventually all of those pieces add up.
Another thing that helps is that when you realize your code has gotten kind of disorganized and messy, go back and reorganize it and make it more consistent and readable (e.g., standardize conventions for variable names and function names). Even if you can only tackle one piece of it, that'll help you develop those habits so you can apply them from the start of your next project.
posted by Blue Jello Elf at 8:19 PM on July 19, 2012 [3 favorites]