I don't think the NSA sharing the data they collect is the problem. The real problem lies in what data the NSA--as a government agency with special powers--collects. Could making some of this more public be the thing that finally leads to a change in the NSA's blanket surveillance over citizens? (Actually, I'm not that hopeful.)
> I've heard stories from a technical director at a major American firm where they'd reject PHDs > simply because they were worried they'd leave for higher paying jobs elsewhere.
Employers who think this way will ultimately hire the employees they deserve.
Pay is not the only thing that attracts a person to a job (or keeps them there). A person leaves for a *better* job, which may or may not mean it offers higher pay.
I predict that NONE of those surveyed will say "to be able to make phone calls" either.
I think that security is something people don't think about very much, but they also buy the phone with the assumption that *surely* it would be made secure, ("they would be fools sell it to millions of people if it were not secure").
And, to a reasonable extent they *are* made secure. But securing a device is a process, not a one-time event. It is an ever-escalating back and forth between having all known holes plugged and an intruder finding the next one (which is presumably harder to find).
The only problem with this is that the recipient gets stuck with a printer whose ink is expensive. The Salvation Army is in no better position to use an inkless printer than you are.
If people are not keeping the comments in synch with the code, *that* is the maintainability issue. Bad comments (not concise, not informative, not clear) may be harder to keep up-to-date, but that's not any different from poorly-written code being hard to understand or update.
Comments should be viewed as an intrinsic part of the code--and if you change the machine-oriented part you better be sure that the human-oriented part is updated to reflect the change. And if necessary, improve the comments while you're at it.
Re:Depends on function
on
Clean Code
·
· Score: 4, Interesting
This is dead wrong. It's true that sometimes purity is sacrificed for performance. But in general, good clean code matches a good clean design, which emerges when a problem is well-understood. Even code that has been tweaked to exploit certain compiler anomalies can remain clean.
This is simply wrong. A good diagram will clearly reflect your actual design. And the exercise of creating one will often highlight problems in what you are doing. Not only that, it will show, in a non-code representation, what your intent is, and this allows others to verify it (and makes sure they are thinking what you are thinking).
Documentation is a fundamental part of good design. Skipping it is evidence of weak engineering discipline.
Liberal arts degrees aren't necessarily easy, and technical degrees aren't necessarily hard. One emphasizes breadth, the other depth, and there are people who would do better in one than the other.
If you're really serious and willing to learn, get a liberal arts college degree and a technical graduate degree.
Refactoring is not rewriting. If done correctly it preserves the semantics of the original code. Code that has become unwieldy is broken; in my view the ugliness and unmaintainability is itself a bug (even if it operates correctly).
Refactoring for "purity" is not an end in itself, it is a means to keeping code readable and maintainable. The need to refactor needs to be weighed against other engineering goals, including meeting near-term schedule constraints.
But it is a process that must be done to a certain degree, continually, as code matures. It allows the actual underlying design to remain clear, even as it evolves gradually in the face of features, bug fixes and fine tuning.
Dealing with complexity is a fact of life. Allowing unnecessary complexity to fester is foolish.
Slashdot Mirror
I don't think the NSA sharing the data they collect is the problem. The
real problem lies in what data the NSA--as a government agency with
special powers--collects. Could making some of this more public be the
thing that finally leads to a change in the NSA's blanket surveillance
over citizens? (Actually, I'm not that hopeful.)
> I've heard stories from a technical director at a major American firm where they'd reject PHDs
> simply because they were worried they'd leave for higher paying jobs elsewhere.
Employers who think this way will ultimately hire the employees they deserve.
Pay is not the only thing that attracts a person to a job (or keeps them there). A person leaves
for a *better* job, which may or may not mean it offers higher pay.
They must use middle-out compression.
I predict that NONE of those surveyed will say "to be able to make phone calls"
either.
I think that security is something people don't think about very much, but they
also buy the phone with the assumption that *surely* it would be made secure,
("they would be fools sell it to millions of people if it were not secure").
And, to a reasonable extent they *are* made secure. But securing a device is a
process, not a one-time event. It is an ever-escalating back and forth between
having all known holes plugged and an intruder finding the next one (which is
presumably harder to find).
The only problem with this is that the recipient
gets stuck with a printer whose ink is expensive.
The Salvation Army is in no better position to use
an inkless printer than you are.
If people are not keeping the comments in synch with
the code, *that* is the maintainability issue. Bad
comments (not concise, not informative, not clear)
may be harder to keep up-to-date, but that's not any
different from poorly-written code being hard to
understand or update.
Comments should be viewed as an intrinsic part of the
code--and if you change the machine-oriented part you
better be sure that the human-oriented part is updated
to reflect the change. And if necessary, improve the
comments while you're at it.
This is dead wrong. It's true that sometimes
purity is sacrificed for performance. But in
general, good clean code matches a good clean
design, which emerges when a problem is
well-understood. Even code that has been
tweaked to exploit certain compiler anomalies
can remain clean.
> Ditch your diagrams.
This is simply wrong. A good diagram will clearly
reflect your actual design. And the exercise of
creating one will often highlight problems in what
you are doing. Not only that, it will show, in a
non-code representation, what your intent is, and
this allows others to verify it (and makes sure they
are thinking what you are thinking).
Documentation is a fundamental part of good design.
Skipping it is evidence of weak engineering
discipline.
Liberal arts degrees aren't necessarily easy,
and technical degrees aren't necessarily hard.
One emphasizes breadth, the other depth, and
there are people who would do better in one
than the other.
If you're really serious and willing to learn,
get a liberal arts college degree and a technical
graduate degree.
Refactoring is not rewriting. If done correctly it preserves the semantics of
the original code. Code that has become unwieldy is broken; in my view the
ugliness and unmaintainability is itself a bug (even if it operates correctly).
Refactoring for "purity" is not an end in itself, it is a means to keeping
code readable and maintainable. The need to refactor needs to be weighed
against other engineering goals, including meeting near-term schedule
constraints.
But it is a process that must be done to a certain degree, continually,
as code matures. It allows the actual underlying design to remain clear,
even as it evolves gradually in the face of features, bug fixes and fine
tuning.
Dealing with complexity is a fact of life. Allowing unnecessary complexity
to fester is foolish.