|
What employers look for is varied, depending on a lot of things like the size of the organization or the management style
The other day I was talking to one of the HR guys (a most un-catbert like individual) and he said that what they mainly want to know in interviews is whether the candidate can use prior knowledge and experience to do his job
So say they want someone to maintain their ASP.NET website. The ideal candidate would already have several years experience in doing just that, but failing that (which is usually the case), they would try to get someone with at least some experience in some .NET technology. Hiring a Linux kernel developer is not going to be a good idea here.
Another thing is whether they will fit in with the team. Some rock star programmer is not going to cut it in a large corporate environment, they would rather go for someone with less ability who works well with the team than a super coder who is socially inept and pisses everyone off.
This would probably be less of an issue in startups, where they do want people who are super performers at the expense of social skills.
Code quality is something that they won't find out in interviews. Maybe they look at your github repo or something, but there aren't nearly enough people who even have one in the first place. Or maybe they throw out the duds during the first few weeks at work, not that I have seen it happen very often.
The cynic in me says that employers want people who work long hours for peanuts and not raise a stink about it, but I guess that would be a shortsighted policy.
|
|
|
|
|
California 90025 wrote: there is no objectively "well written" software
It's often easier to spot badly written software and there seems to be some consensus on what that is. Just last week I had to work with some SQL code that was written like SELECT somefields FROM table1, table2 WHERE table1.id = table2.table1_id. Now that's fine code... If you live in the 80's before proper joins were invented. I even found a where ... ( +) (it was Oracle) that I couldn't even read. Apparently the ( +) is an outer join from before outer joins were invented.
You may be thinking it was an old project and people didn't know better at the time, but actually that code was written two weeks ago 
Ask a million serious SQL developers what they think of this code and I think (hope) at least 99% would agree that it was actually bad code.
Now replace it with proper joins, ask those same developers again and now your developers will be squabbling about casing, indentation and even the order in which you write your where-clause 
|
|
|
|
|
California 90025 wrote: Another thing is there is no objectively "well written" software. When you go out into the industry (I'm assuming you still haven't or are new to it), you will come across all kinds of a-holes who find fault with every f-ing thing no matter how well it's written. I think there was someone who posted here about how the boss rejected his code because the others were too incompetent to understand it.
I've wondered about this, as someone who has not yet worked at a shop. I hear a lot about how there really isn't any ideal code and "as long as it works, it's fine" but at the same time, there are highly acclaimed books and articles that suggest that there is in fact a "right way" to write code, such as Code Complete by Steve McConnell, and that Clean Code book by Uncle Bob.
Ultimately, of course this is just their suggestions, but nonetheless, they seem to be well-accepted suggestions. Though, I believe every word you say about people picking apart your code no matter what, I may not have worked at a shop yet, but I've been working with people for a long time, lol.
|
|
|
|
|
California 90025 wrote: California 90025
I assume this means you're around WeHo? I'm in Studio City.
Jeremy Falcon
|
|
|
|
|
You'll often learn more from looking at poorly written code, because you're fixing it in your head, and coming up with new ideas -- so the worse the code, the better.
Is the windows 10 source code available?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
You're a cruel man! 
I suspect that Win10 was actually pretty well written - the problem is that it's badly designed. It fits an "ivory tower" ideal rather than the real world, and that's where the problems start. Then patches get chucked in to make the ideal sort-of-work in the real world (despite the real world's strenuous objections) and that makes the situation worse.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Whoa!
Are you saying that the ribbon and baby blocks are "ideal world"?
Only smoke the wool from the black or white sheep, Griff. Leave the green ones be.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Nope, they're solidly Ivory Tower! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Writing "Clean Code" is a wide field. My point is, that is a design problem and has to do with software architecture. So reading some clean code wont help you anyway.
Maybe this book about clean code helps you developing such skills.
"Clean Code" isnt for itself but
- avoid bugs with sound and state of the art principles and
- mostly maintainability. (my main point, because I use code with 10+ years)
By that the coding speed increases and the cost of development are sinking. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
This may attract hoots of derision but actually a lot of the MS open-sourced code is quite high quality. Look at (for example) Entity Framework or Orleans on GitHub?
|
|
|
|
|
The problem with that is a lot of it is subjectivity. For instance...
var x = (y == 5) ? 0 : 1;
var x;
if(y == 5) {
x = 0;
} else {
x = 1;
}
var x;
if(y == 5)
{
x = 0;
}
else
{
x = 1;
}
var x;
if(y == 5)
x = 0;
else
x = 1;
And who's really right or wrong?
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: And who's really right or wrong?
COBOL's right, of course:
IF y = 5 THEN
x = 0
ELSE
x = 1
END-IF.
(Whatever you do, don't forget the fullstop)
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: COBOL
How DARE you mention that... that... THING here in the Lounge! To the Soapbox with you!
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Nothing wrong with COBOL
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
The third option is correct.
Jeremy Falcon wrote: And who's really right or wrong?
I am.
|
|
|
|
|
your first example is not the same as the others:-
?: is NOT if-then-else...
var x = (y == 0) ? 0 : z / y;
var x;
if (y == 0) x = 0; else x = z / y;
If it were easy then anybody could do it.
Wait, .... what!
|
|
|
|
|
I'm not sure if this is sarcasm or not. 
Jeremy Falcon
|
|
|
|
|
To me, studying what good code looks like and the best practices thereof has more value than looking at somebody else's code. I consider the reference article here[^] to be of more value than a bunch of code.
If you want to lose your mind, read the source for the stl libraries.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
As a recommendation I'd always suggest having a look at the GitHub repo for Doom & Doom3 (from John Carmack at id Software). Doom written in C and Doom3 in predominantly C++.
GitHub - id-Software/DOOM: DOOM Open Source Release[^]
GitHub - id-Software/DOOM-3-BFG: Doom 3 BFG Edition[^]
Although a lot of the work is in game development and graphics (and in C), I found it useful to look at how it highlights good project and code layout.
Like people have said already in this thread, I wouldn't look at the code to "learn how to write code" but rather to learn what good "coding practices" result in. Keep in mind some of this code has been cleaned up before publishing on GitHub.
K
|
|
|
|
|
Thank you!
Yeah, it seems writing good code stems from both design and good coding practices...
Currently, I am reading the books Code Complete and Clean Code by Uncle Bob. Code Complete seems to focus more on the design aspect stuff, and Clean Code seems to focus more on the actual code-writing practices.
However, Simply looking at projects gives me at least some insight into the coders' styles out there and what type of code I will run into out there.
|
|
|
|
|
|
First, reading lots of code is the RIGHT approach. Kudos. To put it into reading/writing books, I would say that someone who actually writes a (decent) book has read THOUSANDS of books first. It just makes sense.
Second, you can learn from ANY code. Even if you learn "Ouch. That's terrible". B-Movies exist. They remind us what works in good movies, and what doesn't work.
Third, consider reading the (source code for) well understood concepts. Compilers (GCC?). Compiler theory is pretty stable. the concepts of cross compilers, linkers, etc. are all well understood. Optimizers, for example, re-teach indirection (converting code to pseudo assembler, optimizing that, then generating the assembler already optimized). Allowing the optimizer to be shared!
Finally, a discussion about engineering... Most people think that engineering is about perfection. It is actually about making things Good Enough. Optimizing the 3 corners of the triangle of (Fast, Right and Cheap). You can only optimize 2 of the 3, and you agree to sacrifice the third. You can optimize only 1, and sacrifice the other 2.
I learned about this from an engineer neighbor who was designing a factory floor with equipment mounting technology. His junior engineer was calculating the EXACT bolt sizes required based on the machine and the other variables. He made him go back and find the Most Common Denominator to reduce installation issues and mistakes.
In words developers can understand. I have a compiler to sell you. It's NEW warnings are guaranteed to reduce the number of bugs by 10% in your code. It costs $1 Million per seat. Interested?
I hope not!
So, keep reading code.
Then find useful code, like Notpad++, and work on compiling it and testing it.
Then find a list of bugs for that Product and start fixing them and testing your solutions.
You should quickly learn a couple of things. Like having a set of automated tests makes you feel safer to make changes and know if you actually broke something.
I would finish it off with. BREAK the software. Find what tests fail, and how. It's insightful!
|
|
|
|
|
You are asking a FANTASTIC question, and you should be HIGHLY commended for your EXEMPLARY judgement and acumen for seeking such recommendations. (Of course, I can say that because I asked the same question myself about six months ago!  )
Among the many helpful replies that I got in that thread, the one from BillWoodruff[^] was the most extensive and helpful.
|
|
|
|
|
Starting in 1975, when I had an epiphany, I have been writing code that I find I could easily maintain. The code was written for clients, both in-house and external. It ranged from real-time to interactive financial systems; from assembly language to high level languages (yes, even COBOL and FORTRAN).
The key to my success was, I believe, the strict use of coding standards. These coding standards were applied to all my code, not just deliverables to clients but also to code developed during research and experimentation. When a chief programmer (team leader, these days), I required the entire team to use an unambiguous set of coding standards.
I have published some of these standards on CP under the guise of "guidelines." But more importantly, I offer as examples the code in any of the articles I have published on CP. As I said, I use the standards whenever I develop code. It is now so automatic that I seldom need to think about it (so much for the argument that standards slow you down).
There is an unfortunate perception that applying standards makes software cost more. Agreed, as an organization starts using standards, code reviews are needed to assist programmers in achieving standards compliance. But once it's happened, you'll be amazed at the result. Not only is the software maintainable (reducing the long-term cost) but it is reusable (as a colleague once said "good software that you do not need to write is very cheap").
Gus Gustafson
|
|
|
|
|
Last week, MS wanted to update my laptop. It was late, so I hibernated it instead, figuring it would save the state and I could complete it the next evening. The next evening, when I went to do that, I found that MS had turned my laptop on so they could do their update, and then left it on once they were done. Good thing I make a habit of leaving it plugged in when its not in use. Clearly MS has decided that when they want to do an update, the only thing that will stop them is if the laptop battery dies in the middle of it.
A week later, last night, they updated again, this time whacking the mouse settings into unusability and forcing me to uninstall the mouse driver before they would allow the mouse settings dialog to run.
After two botched updates in two weeks, I've given up on Windows 10 and have reverted my laptop back to 8.1. Anyone else giving up on Win10?
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
