Is it the word “lawyer” or spending some small amount of money?
Lawyers are bound by law and an ethical code to conduct business in a particular way. They also tend to have support infrastructure and continuity plans that private individuals do not.
If making sure something actually happens is important to you, this is the best option.
Douglas Crockford, author of “JavaScript: The Good Parts” has said:
“JavaScript is the only language in the world that people think they write without learning it first.”
I think this is a true statement (well, that and bash).
Programming and Software Engineering are related, but distinct fields. Programming is relatively easy, Software Engineering is a bit harder and requires more discipline in my opinion.
Just to be clear, that is not exclusive to “engineering,” as other professionals have similar legal requirements (doctors, lawyers, fiduciaries).
More generally, on a personal level, people are expected to act with integrity, and we have laws that provide them legal protections for whistleblowing.
The actual practice of engineering is about problem-solving within a set of constraints. Of course the solution should not harm the public, and there are plenty of circumstances where software is developed to that standard.
When a PE stamps a plan, they are asserting that they personally have reviewed the plan and process that created it and that it meets a standard for acceptable risk (not no risk!). That establishes the boundary of legal liability. In software, we generally do not have that process that fits in a legal framework, but that doesn’t mean that professional software engineers aren’t making those assessments for life-critical systems.
For other kinds of systems, understand that this is a new field and that it doesn’t have the bloody history that got “real engineering” to where it is today. A lot of the work product of most software engineers just don’t have stringent safety requirements, or we don’t understand the risks of certain product categories yet (and before you try to rebut that, remember that “building codes are written in blood” because people were applying technology before it was well-designed/understood).
Anyway, “engineering” is defined by a lot more than if you or your boss has a stamp (and in point of fact, there are plenty of engineers in the US that work as engineers without being a PE, or with any intention of ever having the stamp. Are they real engineers?)
You should do some research on wasm.
You can run frickin’ docker containers in the browser now.
I don’t make the rules.
Rebasing and merge conflicts are the top ways that git can turn into a mess. I know that rebasing could (in some circumstances) make merge conflicts less of an issue, but I just mostly think the value of “commit grooming” is overrated. I don’t want to argue about this, if you like doing it, go ahead.
I’ve used the git cli exclusively for more than a decade, professionally. I guess it varies wildly by team, but CLIs are the only unambiguous way to communicate instructions, both for humans and computers. That being said, I still don’t mess around with rebase for anything, and I do use a gui diff tool for merge conflict resolution. Practically everything you need to do with git can be done with like 10 commands (I’m actually being generous here, including reset, stash, and tag).
Well, a couple things:
My points are related to provable advantages to doing it while writing code. They’re also not argumentative.
Your points are related to a personal preference of aesthetic while reading code. They are not provable advantages. They’re also quite “ranty,” which is rarely a persuasive way to convince someone of your position.
If you actually want to get people to change their habits around this, I think you’ll have better luck with my approach than ranting about why you don’t like how it looks.
Along with this, once you’ve dealt with enough kinds of problems, you end up developing an intuition for how something was probably implemented.
This can help you anticipate what features are probably included in a framework/library, as well as how likely they are to work efficiently/correctly (you know that XYZ is a hard problem vs. ABC which is pretty easy for a journeyman to get right.)
As an example, a friend of mine reported a performance issue to a 3rd-party vendor recently. Based on a little bit of information he had on data scale and changes the 3rd-party made to their query API, he basically could tell them that they probably didn’t have index coverage on the new fields that could be queried from the API. That’s with almost no knowledge of how the internals of their API were implemented, other than that they were using Postgres (and he was right, by the way).
That’s not always going to happen, but there are just a lot of common patterns with known limitations that you can start to anticipate stuff after awhile.
I would recommend email for this. It’s a text-based protocol and the original RFCs 821/822 are pretty straight-forward. There are some additional rabbit holes related to content encoding, but if one can implement a simple MTA, a huge amount of the magic of the internet becomes accessible.
I would not recommend trying to build a “production grade” MTA, as there is a lot of minutia to get right, and it’s easy to screw up.
I agree with the need, but not your rationale, I’m in the “always curly braces” camp for two reasons:
I believe the setting is user.email so maybe confirm that’s what you have set in both? Git will silently ignore settings that aren’t used/defined.
And you can do the previous years of the coding challenge at any time.
I took some time off, and this was a good source of solving “real” problems, rather than trying to write something to optimize for l33tcode (which, is fine… just not a good measure for typical software engineering responsibilities, IMO).
deleted by creator
Like I said in my other comment, I think people tend to lump all of MSFT’s activities into the same bucket. DevDiv has always seemed pretty decent, and I am usually reminded of this comic when people talk about MSFT’s “shady” activities.
Everything is temporary. If we were talking about a niche language, I might worry a little bit that it could just lose momentum and die. But TS is a juggernaut. The only way typescript “dies” is if JS integrates enough of its features to make it redundant.
Besides that, if Oracle managed to allow Java to continue to grow and flourish, I have confidence that MS can do at least that well. I also think lumping all of MS’s products into the same boat is a mistake. They have been pretty good stewards of their languages for decades.
It’s necessarily complexity that is easily encapsulated in methods.
If those methods are under test to verify their behavior, trivial typos can be detected instantly, without adding another dialect and more conceptual overhead to a project.
If those methods are not under test, then there’s a tiny bit of help by using a DSL if it can be compile-time checked.
I used to be full on the ORM train. Now I’m a little less enthusiastic. What I actually think people need most of the time is something closer to ActiveRecord. Something that can easily map a result set into a collection of typed objects. You still generally write parameterized SQL, but the work of translating a db decimal into the correct target type on a record object in your language is handled for you (for example). In .net, Dapper is a good example.
I also think most people overemphasize or talk about how other programmers “suck at SQL” waaayy too much.
IMO, for most situations, these are the few high-level things that devs should be vigilant about:
On most of those points, if you don’t have aggregate query counts/metrics on query performance on your clusters, starting to get cute with complex queries is flying blind, and there’s no way to prioritize what to optimize.
For the vast majority of cases, simple, obvious selects that don’t involve special db features are going to do the job for most applications. When the database becomes a bottleneck, there are usually much more effective ways to handle them than to try to hand optimize all the queries.
Lastly, I have a little bit of a theory that part of the reason people do/do not like looking at SQL in code is because it’s a hard context switch from one language to another, often requiring the programmer to switch to “stringly-typed” mode, something we all learn causes huge numbers of headaches in our first few months of programming. Some developers accept that there’s going to be different languages/contexts and not all of them are going to be as fluent or familiar, but accept that this is par for the job. Others recoil from the unfamiliar and want to burn it down. IMO, the former attitude is a lot more productive.
Many of the “frivolous” lawsuits you’ve actually heard about are effectively smear campaigns against the plaintiffs.
The lawsuit against MacDonald’s for the hot coffee one is a great example.
Yes, people do dumb stuff, or fantasize that a situation could be their golden ticket, but that is the cost of having a civil judicial system. You either have to allow some crazy in, or prejudge and filter out what you’d consider legitimate cases. I just don’t have the energy, or care enough to be annoyed by inefficiency in the a system that I rarely interact with.
The criminal system is a different story, because the way we currently prosecute different kinds of crimes offends my basic sense of fairness.