this is like the fifth time i've seen this same flame-bait article reposted.
Engineer:
- a person qualified in a branch of engineering, especially as a professional.
- the operator or supervisor of an engine, especially a railroad locomotive or the engine on an aircraft or ship.
- a skillful contriver or originator of something.
if you're upset because you don't feel like simple programmers should call themselves "engineers" because they didn't spend 7 years in an expensive college to earn the title, or because they are not making physical bridges and buildings, consider the following:
1. software "engineers" build (software) machines for people to use. they have to take technical requirements and turn them into structure and functionality.
2. most software design is an iterative process: you have to make solid foundations to build upon and it's a skill that has to be acquired through experience. i.e. you build infrastructure.
3. it's not rocket science, but programming (and related skills like network administration) are highly technical and take lots of practice and study to become proficient
4. often have to build things within a constrained or otherwise limited context. given a problem to solve and a list of requirements and constraints, design a solution
Now, that being said, not every "engineer" is a good engineer.
there is no reason for the SSN digits unless you actually get a legitimate offer. there should be no reason to even ask your DOB at this stage, but that's slightly less worrying. but most of all, i've never gotten a job from a recruiter that was worth it. they are trying to get a commission and that is all. apply directly for jobs YOURSELF. stay away from 3rd-party recruiters.
i wouldn't trade salary for it. i don't think it's a scam but i wouldn't be surprised to find some employers use it to take advantage of workers.
at my shop we are encouraged to take as much time as we need and managers even regularly encourage us to take more time off.
sometimes i feel like it's a trick and i don't take as much time off as most people do. they do track how many days you take off but you can come in late whenever you want and use 1/2 day pto if you don't want to stay late. or, if it's nice outside, take a personal day for the hell of it.
the only consideration is we have to be sure to have someone covering any ongoing work so we still meet deadlines.
tldr; read kent beck's original book on the topic before you form your opinion. TDD is not a silver bullet and it's not 100% required to write quality software. but it is a useful tool, and you probably are doing it wrong. if someone taught you at work or school, there is a good chance they were doing it wrong. if you still don't see the point after kent's book and the video that i've linked below, then at least you know the most common arguments for both sides now.
i'm a proponent of TDD and unit testing but i don't TDD all the things. there is, as in all things, a balanced to be achieved between test coverage and delivery time. some parts of the system - primarily the business logic - need thorough testing. other parts of the system, especially those that don't change often, can require less testing. additionally, many people and organizations misinterpret the basic concept behind what Kent Beck describes in his book and end up implementing lots of complicated, brittle tests that eat development time and slow down the entire process.
#1 read Kent's book. seriously, do this now. don't just assume you understand TDD because it sounds so obviously simple
#2 watch Ian Cooper's excellent talk: TDD Where Did it All Go Wrong? https://vimeo.com/68375232
i will say that, even after nearly a decade of writing tests, i didn't really understand why my tests were so brittle until i watched #2. turns out i didn't realize what a 'unit' _really_ was, WRT writing tests.
now that you know how and what to test, a few tips:
#1 keep "unit tests" separate from "integration tests":
- unit tests do not do any actual I/O, run very fast, test "units" in isolation
- integration/system tests run over entire systems or sub-systems, rather than isolated units
- actually do I/O: db, disk, etc
- are slow, but you don't need that many of them if you have good unit test coverage
- this point will be made more clear in the video linked above
#2 write tests to an interface, not to an implementation
- when you write a test that depends on implementation details, it will be brittle and cause trouble when that implementation changes
- when you write a test to an interface, the implementation details should be irrelevant (to a degree). you care about the "what" (inputs/outputs/exceptions), not the "how"
#3 inversion of control and dependency injection are your friends
- the video linked above should give you an idea of what i'm talking about, WRT hexagonal architecture
- if you create an object in the function under test, it's hard to manipulate that object to drive the test
- if the function under test accepts that object as a param, you can configure it before calling the test or replace it with a mock object
#4 be wary of overuse of mocks!
- when you end up with tests that are just lots of mock expectations describing the interaction between two objects, you are testing implementation!
- lose the mocks and write a system test instead
#5 tests are production code! you will need to put the same effort into making them readable and maintainable. you might even have to write tests for some of your test support code
Engineer:
- a person qualified in a branch of engineering, especially as a professional.
- the operator or supervisor of an engine, especially a railroad locomotive or the engine on an aircraft or ship.
- a skillful contriver or originator of something.
if you're upset because you don't feel like simple programmers should call themselves "engineers" because they didn't spend 7 years in an expensive college to earn the title, or because they are not making physical bridges and buildings, consider the following:
1. software "engineers" build (software) machines for people to use. they have to take technical requirements and turn them into structure and functionality.
2. most software design is an iterative process: you have to make solid foundations to build upon and it's a skill that has to be acquired through experience. i.e. you build infrastructure.
3. it's not rocket science, but programming (and related skills like network administration) are highly technical and take lots of practice and study to become proficient
4. often have to build things within a constrained or otherwise limited context. given a problem to solve and a list of requirements and constraints, design a solution
Now, that being said, not every "engineer" is a good engineer.