Letters to Junior Developers
codeovereasy.com
Letters to Junior Developers
1–10 of 34 posts
Re: Letters to Junior Developers
#2In the same vein: http://learnpythonthehardway.org/book/advice.html
Re: Letters to Junior Developers
#3Great advice! I would agree with everything except maybe that “I just had to hack something together…” always is a bad thing.
Especially from the business point of view this article stresses, it can be reasonable to 80/20 your way out of certain problems and then polish it in the future.
Re: Letters to Junior Developers
#4Great advice! I would agree with everything except maybe that “I just had to hack something together…” always is a bad thing. Especially from the business point of view this article stresses, it can be reasonable to 80/20 your way out of certain problems and then polish it in the future.
I also think it presents a highly optimistic view of the average manager.
Re: Letters to Junior Developers
#5Great advice! I would agree with everything except maybe that “I just had to hack something together…” always is a bad thing. Especially from the business point of view this article stresses, it can be reasonable to 80/20 your way out of certain problems and then polish it in the future.
I also think it presents a highly optimistic view of the average manager.
As well as your average customer. Your average customer couldn't care less about the maintainability, testability, or cleanliness of the code. They care about getting the features they asked for within the time frame they were promised for the price they were quoted. You could argue that those things all play into that and are things they should care about and I wouldn't disagree. But the reality is they don't. If you tell them you have to push it back because you need to clean up the code and make it look pretty you're going to have an unhappy customer.
Re: Letters to Junior Developers
#6"Some organizations pretend that they are about other things, like serving people or changing the world. But in truth they are measured by money."
And in practice they rarely are not. Nobody calculates the total cost of an unnecessary two hour meeting where 8 highly-paid employees discuss about something almost completely irrelevant.
Another problem with this is that it's extremely difficult to calculate anything when it comes to software, so expenses and profits are usually created using Stetson-Harrison when some higher-up needs a budget.
In fact, I'd say that companies that don't have such an "accounting" focus on software development do a lot better.
Re: Letters to Junior Developers
#7Whenever I tell recruiters or career councilors that I am looking for 'junior developer' jobs they look at me like I am crazy, like such things don't exist and that I don't and to work hard or do real software development. So it is nice to know a decade after getting a Computer Science degree that such jobs may actually exist.
Re: Letters to Junior Developers
#8Great advice! I would agree with everything except maybe that “I just had to hack something together…” always is a bad thing. Especially from the business point of view this article stresses, it can be reasonable to 80/20 your way out of certain problems and then polish it in the future.
The problem with the "Don't hack things together" advice is that it's invariably written by developers who like to write code, enjoy writing about code, and want to be seen as thoughtful and influential people in their development community. Those sorts of people tend to gravitate towards the projects that have the scale where code quality is critical because what they work on lasts for years with thousands of people building on it.
If you're a developer who throws code together in a few months for clients who aren't paying for a quality product, and maybe you'll come back to it a couple of times in the future when it needs a new field added or a page title changed, then a hack is perfectly valid and can hugely improve your business's bottom line over spending even just another 10% making sure you've got tests and documentation and defensive code and so on. Spending time on the maintainability of code that no one will ever maintain is a waste of time.
Re: Letters to Junior Developers
#9I really don't agree with the final "Present a solution, not just a problem" point. Quite often a developer will be able to see a problem but won't have a clue what the solution is. Having a "Present a solution, not just a problem" approach means that developers won't want to inform you that the problem is there, and then it'll surprise you later at the worst possible time. If you have a solution, great. If you don't, also great. But always communicate a problem exists.
Re: Letters to Junior Developers
#10Nice writeup, with the exception that you should never, ever "love something so much you'd do it for free" in a professional setting. I get that the intention behind the statement isn't literal, but that kind of attitude is what makes hiring managers think that they can make junior developers sub-25k offers in places like Manhattan.
I had the confidence to never allow myself to be low balled and quite enjoyed the lectures about "paying my dues" and "being thankful to have an offer in this field/economy" - the looks on their faces when I still rejected the offer doubly so. But not every hopeful developer has that.