61–70 of 73 posts
On tip #1, how big does the chunk of other people's code need to be to teach you about the things he's talking about? I've really enjoyed reading algorithms but struggled when looking at source code for large projects on github. I often feel lost and don't really know how to dig in. Any suggestions?
One other major suggestion I'd add: Practice writing. Just write whenever you can, in whatever environment, no matter how unformal. Your company wiki, your personal blog, whatever. Maturing from a "junior" engineer into a more experienced one usually means initiating suggestions, not just following them. As the OP said -- have an opinion! But your suggestions will always be limited to how well you can communicate the…
And I who entered this business because I liked to deal with computers, rather than humans. How do I avoid becoming a writer, while still being able to have a job as a software developer?
That of course doesn't answer your question. You can probably keep your job whilst having poor communication skills but that will be a (significant) limiting factor for you.
Earlier quoted context omitted.
My experience as a junior engineer is completely opposite to yours. I'd also suggest finding another job--your current gig is not offering you a good environment to grow and learn.
Where are you and where is the GP? Cultures around the world are different. My experience as a junior developer in London around 2004 was very similar. Especially that whole "don't be late" thing which really really annoyed me and I'm still coming to terms with.
Earlier quoted context omitted.
And I who entered this business because I liked to deal with computers, rather than humans. How do I avoid becoming a writer, while still being able to have a job as a software developer?
Most of us like handling computers more than humans but it's not really that black and white. In order to get the most out of your career you will need to learn how to handle humans too. That of course doesn't answer your question. You can probably keep your job whilst having poor communication skills but that will be a (significant) limiting factor for you.
Earlier quoted context omitted.
I'm currently a, "something" developer this is what I would tell you over a beer after a hard days work in the salty salt mines of programming, after 6+ years on the job. > Making mistakes will kill you Nah they won't. No matter how it's worded, your current agreement with your employer is actually something like: "We agree that you will make mistakes and learn on the job. In return for this we will pay you peanuts".…
Thanks for your advice and information - personally, I agree with a lot of the points you've made. The problem is that at the time I took my job, I didn't have much choice, I was in a shitty position, no job, no money, no home, etc. and I took the fist position which came along. I wish I had been in a better position and been able to better evaluate my current workplace, but in my bosses defence, I am the first (out…
No shame in that. I graduated in 2001, and was ecstatic to receive my first (and only) job offer. 1.5 years later, the company went bankrupt, and my team of ~7 was sold (OK, the IP was sold, the team got offers). News came out that one person on the team was getting a raise during the transition and that person was me!!
...because the new company didn't have a pay grade that went low enough to accommodate my existing salary. :/
About 5 years later I cracked 6 figures in the Midwest U.S. and I'm not a super/rock/ninja/adjective du jour star by any stretch. My $.02: Keep working hard, know what you want (and don't be afraid to ask), communicate well, and generally be a Good Guy/Gal™. The rest kind of fell into place for me and my guess is that it will for you too. Best of luck!
Earlier quoted context omitted.
No. They are part of the curriculum in a good SE degree. There is a SWEBOK. http://www.computer.org/portal/web/swebok
I found, based on my few years of experience lecturing in IT and BIS at a large university (72,000 students), was that very little emphasis was placed on building up IT as a profession based on a body of knowledge. Really, it just isn't happening. There is a huge disconnect between best known practices, such as those you linked to, and academia.
On tip #1, how big does the chunk of other people's code need to be to teach you about the things he's talking about? I've really enjoyed reading algorithms but struggled when looking at source code for large projects on github. I often feel lost and don't really know how to dig in. Any suggestions?
I feel the same. I always hear people say to read others code. Really? Like what?
I'm currently interested in C and lower level systems stuff and I've found redis to be a really readable codebase. It's not an introduction to C but provides a good example of how to manage a larger C project.
On tip #1, how big does the chunk of other people's code need to be to teach you about the things he's talking about? I've really enjoyed reading algorithms but struggled when looking at source code for large projects on github. I often feel lost and don't really know how to dig in. Any suggestions?
I also prefer reading through projects I use either as a dependency or as part of a system I'm building.
For that the Apache foundation's projects is an excellent place to start. They have very good documentations and the forums are filled with discussions.
e.g Apache Nutch (before the v2.0 release) - there are many talks and slides you can find on its architecture and the source code isn't hard to read. http://nutch.apache.org/
Twitter's github projects are also very good - especially when I started learning scala.
One project that I read for fun, it was hard to go through but the exercise was worth it is Chromium. http://www.chromium.org/developers
Earlier quoted context omitted.
My experience as a junior engineer is completely opposite to yours. I'd also suggest finding another job--your current gig is not offering you a good environment to grow and learn.
Where are you and where is the GP? Cultures around the world are different. My experience as a junior developer in London around 2004 was very similar. Especially that whole "don't be late" thing which really really annoyed me and I'm still coming to terms with.
We do a lot to mitigate mistakes (code reviews, testing, rigorous QA), but when they happen I'm not getting the switch.
We're taken care of w.r.t wages and time. Hours are totally interchangeable here--if I arrive 45 minutes late, I make it up on the back end. I'm also taking care of a graduate degree out-of-pocket (speaks to both the wage and time thing).
I won't speak to arrogance (fallen into this trap, and you don't want to be the guy asserting falsehoods matter-of-factly), but junior devs shouldn't be afraid of assertiveness. I wasn't happy about something here, and when I was asked to discuss it with our tech management team they (a) listened and (b) acted on it immediately. That's big.
I'm currently a junior developer and will share the lessons of my experience 6 months in: - Making mistakes will kill you, when you sit at home working on your personal projects and a bug slips through, it's not so bad, you can fix them and the client (or yourself) is normally pretty cool with it. On the other hand, when it's someone elses fault, E.G. yourself, your boss will come down hard on you. That's his project…
This does not sound like a positive work environment! This seems to be very unusual.
Also, if you can't make enough to live on, that's insanely unusual in the West.
You need to be able to fail and make mistakes. That's part of being a junior developer. You need to be able to provide intelligent opinions, even contradicting your boss.
But you're right about being aware of the politics and what your boss wants. It's usually bad form to cause one's boss to lose face in front of clients/his peers/bosses.