1. Learning on the job is tough. The specific project I am working on is mostly written in Ember. It’s been a fascinating language to learn (especially since I previously didn’t have much of a background in javascript at all) and I’m definitely learning much faster since I’m building components and working in the language while learning it. But it is tough to learn amidst deadlines and due dates. How much do you need to know? Am I building things correctly in this new language?
2. How much time should I spend on something? This is a tough question. I want to learn and make sure I’m implementing the best solution but at the same time, how long do I take on something before I either move on, ask for help, or just put the best solution I know in place?
3. What is the normal “getting stuck” level? I feel like I get stuck at least once a day. Whether it’s something confusing on git, or a test that is failing, or some functionality I’m putting in place, every day I spent at least an hour trying to figure out how to move forward. Is this normal? Is it not? How much time do I spend “stuck” before I ping someone?
4. This is related to the question above but… when am I learning and when am I spinning my wheels? There’s nothing I hate more than pinging someone for help only to learn that the solution is super small and silly. I know this happens to everyone, but it makes me feel like I SHOULD have seen the solution and not bothered someone else. But then, there are times where I am reading EVERYTHING out there and googling and researching and breaking a problem into pieces and I wonder, am I spending too much time on this?
5. How much of the process should you follow? There are lots of process “things” in the programming world. Whether it’s test first, write code in the red, green, refactor order, spend time refactoring in general, pair, do code reviews, etc. I love all of these things, but I find myself weighing what process I should follow and how strict I should be with the process, knowing that there are deadlines and things that need to get done. I know it makes sense to do something the long way and then refactor, especially since as a newer developer I’ll learn more that way, but is it always worth taking that time? Sometimes worth it? How long should I spend on writing code vs. refactoring it?
This first position is really fantastic. I feel lucky because in most initial programming positions, developers find themselves doing one type of job or spending months on the ramp up. I was thrown into the deep end a bit from the getgo (which I almost prefer) and I get to do different things every day… rails, ruby, database stuff, javascript, etc. It’s great… wonderful and challenging but also stressful. I look back at the last four weeks and think of the crazy amount of information I have learned. It’s so different than self-teaching and working on projects that I created or things from scratch. And yet, it raises a whole new set of questions in my mind. I imagine that other developers feel the same way… especially in their first position.
I remember being confused by this same list of things when I started programming... hard to believe it's been 10+ years ago now. Let me try to field a couple:
ReplyDelete1. You're doubly so challenged because Ember is brand new. I'm learning now and it's still really tough. In my own project, the code has improved immeasurably as I've progressed. In my opinion, it's not possible to learn enough to build things elegantly at first (and because of a dearth of community consensus--common problems are still being hashed out--you're going to have to program anyway to figure out how to do things right). If you frequently have those 'lol I have no idea what I'm doing' moments, you're not alone there. Code review should be a high priority, though, and finding other code to read will be very helpful too, I suspect.
More generally, this problem will stick through you so long as you're trying to grow as a developer. I still experience it on a regular basis.
2. This is a balancing act. No solid answers here; I tend to aim for good craftsmanship, sometimes at the expense of budget. I think you should probably weigh this on a three-axis continuum of business value, finickiness of the code, and time/money available to you. You can always come back, too, to improve an algorithm or pattern once you've spent more time with the project. I leave TODOs in my code all over the place and then just grep for them when I'm cleaning up. (Since you're using rails, you can just use `rake notes`.)
If you have a good senior developer available to you, just getting them listen to you talk through the problem should be an easy way to quickly check if you've got the gist of it after you've done your initial research.
3. Getting stuck is normal and healthy. What's problematic is when you start building up a recursive stack of stuckness. Struggling is good and will teach you much more than simply being told how to do the problem, and for that reason, you shouldn't try to eliminate it completely... but being able to recognize when you're no longer being productive toward generating a solution is important. Again, if you're in contact with a good senior dev, he or she should be able to give you a word of guidance to put you on the right track. As a general heuristic, though, an hour of being stuck or three levels deep of stuckness is usually when I find myself on IRC, asking questions of smarter people. It's also not uncommon that I might be stuck 3-4 times a day.
4. Only you can say. But I should mention this: one very productive thing you can do to diagnose a problem and its solution is to split it into a binary tree. You should be researching with the intent to narrow it down to the smallest possible branch that you can. When you can't winnow that down any more, walk away for 5 minutes, come back and think for 5 minutes more, and if you can't get anything from that point, start asking questions.
5. Eschew dogma. Do what makes sense on a case-by-case basis. Testing first is rarely the wrong answer, but I'm a firm believer that integration tests are only useful as documentation and as a quick spot-check that things are okay, so if that's the only test you're writing, think twice to make sure that the test is actually testing a spot for potential breakage or documenting a system requirement. One of the surest ways to test whether you're testing correctly is to ask whether the tests are actually helping you.
As to the process, I've found that doing red-green is very effective for making sure I've considered all the potential ramifications of my code. Re: why we do things the long way and *then* refactor: if you're writing the least amount of code possible to make a test go green, then you're not introducing unneeded complexity, which reduces the amount of surface area for coding errors to be made. If you are rigorously following red-green(-refactor), you should be predominantly refactoring your code only to make subsequent tests pass, and by keeping these to the bare minimum to make the subsequent spec pass, you'll avoid over-engineering your solution.
DeleteIt sounds like you're really enjoying yourself, which is awesome and critical. When you're tossed in so deep so quickly, it's normal to get a bit of vocabulary confusion, too. I found that the most challenging part of learning to program, and it's *so* much worse now. If you have the spare time, reading up on the API of the tools you're using is very helpful and will, as you start to internalize it, give you a huge boost to your productivity.
Initial learning is a bit like making a spider web: in doing your first few tasks, you'll shoot out into the dark to solve a problem, which becomes the single supporting ray. Every time you solve a new problem, that becomes another ray, and when those rays get a bit closer together, you can start to see how they're connected. The more problems you solve, the more fleshed-in your web of knowledge becomes until it gets to the point where any specific problem you have might not have a ray of its own, but by its positioning between two others is deducible.
Hope that is reassuring!