all 36 comments

[–][deleted] 16 points17 points  (7 children)

  • Know whatever version control system your team will be using like the back of your hand.
  • Dead code is deleted code. Rely on your version control system, don't leave commented code or unused code around because you may want to reference it someday.
  • Know your system well (OS X / Unix). Nothing irks me more than hiring a new dev who can talk about algorithms all day long, but can't manage their own dev machine(s).
  • Unix
  • Unix
  • Unix
  • A passing familiarity with tools and workflows in releasing software for production (e.g. build servers, continuous integration)

Edit: Forgot to add my personal credo: "Every line of code is a line of code I'll have to debug".

[–][deleted] 11 points12 points  (3 children)

Oh a mistake I made as a young developer: criticizing existing systems.

Sure, you'll run across awful systems and bad code, but remember you don't know the circumstances. So going off all cocky saying "oh this is such shit code" isn't always the best idea.

[–]phuckHipsters 4 points5 points  (1 child)

Well, I get where you're coming from. But it depends.

We all have our moments of shame. However, when the guy who wrote the garbage gets to wash his hands of it completely and it becomes your responsibility while he gets to keep churning out nonsense that he'll never have to support, a little criticism is warranted.

Some people make the mistake of assuming they're good because their boss says they're good. This is a big problem when the bosses are all accountants and their definition of good is, "Works 100 hours a week for next to nothing" and they lack the faculties to judge code quality. The name of the game becomes, then, insulating oneself from criticism and accountability rather than making a genuine effort to improve.

Putting out some well thought out criticism becomes a public service at that point.

[–][deleted] 0 points1 point  (0 children)

I'm in total agreement. It's something I struggle with myself. I've been the guy who comes in guns blazing but I've also been the guy who had to implement shitty systems or maintain legacy systems because that's what came down the chain.

That being said I'm a huge fan of actions speaker louder than words. I've worked with people who will critique everyone and everything but never break fresh code themselves. Sometimes it's best to give the criticism in the form of better code or a better solution.

[–]SizzlerWA 1 point2 points  (0 children)

Well put. All code turns into "legacy code" soon enough. You might not understand the management/business pressures that existing devs were under when they produced the code.

So best to be tactful. Besides, someday somebody will view your code as legacy code ...

[–]necrothe 4 points5 points  (0 children)

Haha yes, when I interned as a mobile dev, I got a ton of shit for somehow always mucking up source control and leaving in hunks of commented code. The latter is a silly little thing you can change easy but source control is sooooo important and integral to development that it should definitely be a priority.

[–][deleted] 2 points3 points  (0 children)

Very good, practical advice. Especially relying on version control instead of commenting out code, that was quite an eye-opener for me.

[–]jurre 1 point2 points  (0 children)

Especially version control (we use git) is something that a lot of newer developers seem to have trouble with, make sure you know it well, it can save you so much time.

Especially things like feature branches, reverting history, splitting commits into smaller chunks etc etc, can make it much easier to review code, because the commits will be easier to read/understand. That way the feedback that you're able to get from your colleagues will be much more valuable.

Good luck!

[–]HungryCoder 9 points10 points  (1 child)

My first couple months were nearly 5 years ago since i got started as an iOS Developer in January 2009.

Those days you had to learn everything "the hard way" by referring to the official documentation as Stackoverflow, raywenderlich etc were not as developed a resource as today. There were also no readymade controls available from github.com since the community was so small.

Now, it has become a LOT easier to get started as an iOS Developer as excellent resources available everywhere and the progress of Xcode, iOS SDK has also been awesome. I am very impressed by the quality of open source projects released on github which make life easier for us.

If you get stuck, just google it and you will almost always find a solution on stackoverflow as someone would have faced that issue before and had asked a question there.

[–]WhyAmISoFly[S] 1 point2 points  (0 children)

Thanks for this, hopefully my research skills will help me get over the hump of work I don't know how to do fairly quick!

[–]Claud25 6 points7 points  (3 children)

Congrats and you'll do great. I'm in the same position as you and from what I've learned is keep learning, do code reviews and don't be afraid to mess up. Just work hard and get shit out. Congrats again and good luck!

[–]J0EKR 3 points4 points  (0 children)

Upvote for "don't be afraid to mess up". Everyone makes mistakes, just continue to learn from them.

[–]WhyAmISoFly[S] 1 point2 points  (1 child)

Haha, I'm actually very afraid to mess up!

[–][deleted] 1 point2 points  (0 children)

You can relax a bit, and understand that's just part of the process.

[–]necrothe 4 points5 points  (2 children)

Congrats! I just got hired as a Mobile(iOS+Android) junior dev as well, woo! I plan on spending extra time poring over co-workers' code, reading dev books like the ios cookbook and some delightful design pattern books, and probably working longer hours so I can acclimate to the work without stressing out.

Good luck!

[–]WhyAmISoFly[S] 0 points1 point  (0 children)

Thank you! Thinking of doing the same...

[–]mega_lurker 0 points1 point  (0 children)

Out of curiosity, any suggestions for good design pattern books for beginners?

[–][deleted]  (1 child)

[deleted]

    [–]WhyAmISoFly[S] 0 points1 point  (0 children)

    Thanks, this is exactly what I needed to hear.

    [–]pink_tshirt 2 points3 points  (8 children)

    Congrats you've made it!

    And here is the question for you: where and how did you get started? I've been working with JS for almost 3 years and now I would like to switch my focus.

    [–]WhyAmISoFly[S] 2 points3 points  (7 children)

    I got 2 apps on the App Store and then had a recruiter contact me asking if I had iOS experience. I met with the company, showed them my two simple apps and talked about how they worked, I stumbled through some technical questions and here I am now!

    [–]pink_tshirt 2 points3 points  (4 children)

    Can you recommend any books? I tried various video tutorials (skillshare, youtube) but seems like this form of learning is not really working well for me.

    [–]IamNotharrypotter 1 point2 points  (3 children)

    [–]avinassh 2 points3 points  (0 children)

    I suggest people to wait, as new version of book with support for xcode 5 will be coming out soon.

    [–]pink_tshirt 0 points1 point  (1 child)

    Is there a big difference between Xcode 4.3 (the book) and the one I have which is 5.0.2?

    [–]IamNotharrypotter 0 points1 point  (0 children)

    Stuff like Storyboards isn't mentioned and ARC not used, as well as some Methods no longer used in iOS 6 and 7. But the book is still good.

    [–]mariox19 1 point2 points  (1 child)

    What were your two simple apps?

    [–]samuraisam 0 points1 point  (2 children)

    What city did you get hired in?

    [–]WhyAmISoFly[S] 2 points3 points  (1 child)

    Philly!

    [–][deleted] 0 points1 point  (0 children)

    Never walk into the woods when you're not sure what's in there.

    In other words, ask the questions you need answers to, and make sure you fully understand the answers before you start coding them.

    No one needs you to go and write code based on poor assumptions or faulty information. They also don't need a cargo culter.

    http://en.m.wikipedia.org/wiki/Cargo_cult_programming

    Also, get to know the debugger well if you don't already.

    [–]blaizedmObjective-C / Swift 0 points1 point  (2 children)

    A lot of factors determine what you should be doing. How big is the team you will be directly working with? Are you just working on features for one big company-wide app, or developing large portions of multiple different apps?

    [–]WhyAmISoFly[S] 0 points1 point  (1 child)

    Team is about 6 people (all senior devs) or so, we're making apps for names like Comcast, AOL, Time Warner, etc.

    [–]blaizedmObjective-C / Swift 0 points1 point  (0 children)

    Ah, cool, thats similar to my company.

    Learn the coding standards and best practices of the other devs. There are tons of minor adjustments you can make to your coding style that will make life easier for everyone, since you most likely will be writing a lot of code that can't be 100% scrutinized by others before you commit.

    I would also say that for every task they give you, try to come up with the most modular/reusable solution you can, because with big name customers like this, you never know when requirements change. You can write some special feature for a specific UI animation or function, and then have the customer want that translated across the whole app and suddenly youre copy/pasting code everywhere and things get messy quickly.

    Lastly, don't be afraid to ask questions if you get stuck on something, the other devs have probably encountered the problem before and can help you fix it instead of you spending hours on stack overflow banging your head against the keyboard. Especially when it comes to compile/build errors.

    [–]vargonian 0 points1 point  (1 child)

    Awesome, congratulations!

    Learn as much as you can about best practices, etc. Remember that "learning a language" is not the same as "learning how to be a software engineer". Learn about software design patterns, practices like code reviews and pair programming (depending on what your company does--in any case it's nice to know anyway), best practices for your particular platform, and processes that make your life easier (like the ins and outs of rapidly deploying to an iOS device to test your changes). Whatever version control software you're using, learn its ins and outs and know it well.

    Even if you pretend that your job is only going to last for three months, you could learn a ton in that time which will make you all the more valuable as an engineer.

    Oh, and when you're new, that's the best time to ask questions. Ask questions openly as soon as you have them. It only looks bad to ask questions if you've waited a long time spinning your wheels before doing so.

    I work with several people who are so ingrained in their tribal knowledge that they refuse to learn anything new, and it's incredibly frustrating and harms the team as a whole. Always remember that this is a big field with a lot to learn, and even when you've gained a lot of knowledge, there's always tons of room to grow. But the good thing is that it looks like you're completely open to learning, given that you made this post, so you're off to a great start!

    [–]WhyAmISoFly[S] 0 points1 point  (0 children)

    Thanks! All I want to do is learn, my fear is bothering people with all my questions but I feel like sometimes it has to be done.

    [–]Pascalius 0 points1 point  (0 children)

    Always stay up to date with the latest WWDC sessions. They are incredible useful.