51–60 of 62 posts
10. Requests that begin with, "All you have to do is...". 9. Deadlines fabricated by others. 8. Single character variable names. 7. Being spoonfed requirements on a need-to-know basis. 6. SQL Selects within iterations. 5. Requests that describe how, but not what. 4. Variable names that don't describe what they are. 3. Meetings without beer. 2. Dropping everything for the emergency du jour. 1. Top 10 Lists that infer…
You get meetings with beer? What is this? Madison Ave where everybody has a bottle of scotch in their drawer?
Earlier quoted context omitted.
"These are two separate skills - the ability to lead others, and the ability to work productively without being led." One skill leads to another. If you can show upper management that you have the ability to work without being led, you can eventually become a manager. "I'm not convinced either claim is true to be honest - it's probably more true to say that most people have never had the opportunity to even try to de…
Which is funny - just because you can work without being led doesn't mean you can lead others. One would hope you've gained some insight into how to work without being led and can apply this to others, but that's far easier said than done.
How often does a business/company allow you to work without being led or managed? If that's the case, the company is very small (and you are the manager of yourself because nobody else knows what is going on). The next logical step to this is to hire more people under you.
Most companies aren't going to give you a management role. You need to prove you have the skills in some way.
Earlier quoted context omitted.
Correct! However, I should confess that I usually write it as ii: for (int ii = 0; ii
Why?
I personally find the doubling awkward, and with modern editors I use semantic searching much more than raw text scans so the benefit of doubling is marginal, but there is at least one sensible reason you might choose to do it.
Earlier quoted context omitted.
This is thinking like a user, not thinking like a programmer. As a programmer, you don't want to fix the contact form, you need to fix the need to fix the contact form. This is how you avoid deathmarch projects; you program away the tedious parts so that you have a functioning system instead of a bunch of code that does stuff. Just sayin'.
I'm thinking as an employee, and not as a dreamer living in a world where the boss asks you what sounds like fun.
A lot of the repetitive stuff that professional programmers do could be automated. Writing code to automate the problem and then having the problem itself solved automatically tends to be both more efficient and more interesting than tediously coding up the naive solution many times. However, it also requires actual thought and understanding, where an entry-level drone copying and pasting from a web page can follow the tedious, repetitive approach. This is one reason why good programmers are much more productive than bad ones, and it's one of the reasons good programmers tend to dislike working with bad (naively written, non-automated) code.
Coding standards documents written by people who can barely program.
Earlier quoted context omitted.
That's funny, because "subordinate" has replaced the previous generation's "inferior" as the commonly-used term for an employee down a step in the org chart. However, to answer your question: if someone can determine whether you get to keep your job, whether you like it or not you are that person's subordinate.
"if someone can determine whether you get to keep your job, whether you like it or not you are that person's subordinate." Trying to get my head around this. What does "keeping one's job" even mean? isn't there still a mutual contract, and both parties can break out of it? So the boss can act on behalf of the company, and you can't. But presumably you can still quit the job on your own decision. Does that make the bo…
No, but I suppose it might imply that you could be your own subordinate. Since the boss can fire you, but you can't fire your boss, you have a subordinate relationship.
Earlier quoted context omitted.
Why?
It gives you something you can quickly search for: hit followed by "i" twice and you're there. Do the same with a single-character name, and you hit any time that character appears anywhere. I personally find the doubling awkward, and with modern editors I use semantic searching much more than raw text scans so the benefit of doubling is marginal, but there is at least one sensible reason you might choose to do it.
Earlier quoted context omitted.
It gives you something you can quickly search for: hit followed by "i" twice and you're there. Do the same with a single-character name, and you hit any time that character appears anywhere. I personally find the doubling awkward, and with modern editors I use semantic searching much more than raw text scans so the benefit of doubling is marginal, but there is at least one sensible reason you might choose to do it.
Or you could just search for "i =" or "int i" or "for"?
As I said before, it's probably not as useful with modern IDEs that have semantic search capabilities, but there is a genuine reason some people prefer the "ii" style.