kenoyer130

Also DO NOT CHEAP OUT ON THE FREELANCERS. A good team of freelancers is going to cost MORE then in house developers. The plus side is they are relatively temporary so not a long term financial burden. The projects I see that fail with freelancers are the company gets greedy and pays the bare minimum but as always you get what you pay for. In most cases the work just ends up being thrown away as a CRUD app that does no have your business logic and work flows is actually harmful.

Consider not only freelance developers but a freelance "scrum" type team with a PM or PO. Vet these carefully as a bad PO will sink the project. A good PO will gather requirements, keep the team on track, report back progress etc. Since this is an outsourced solution you must be "waterfall" as in be crystal clear on how the app will work, what is the business logic (the devil in the details) etc. Freelancers will not stop to ask questions or clarifications. They will do exactly as asked no more or no less. While I do agree if software is not your core competency you should not bring it in house it is worth mentioning most software starts as an in house solution that is then upgraded to a commercial offering in the B2B space you operate in. Its a long shot but if you stop thinking of your software as a cost center but as your actual core competency its possible to turn it into a revenue stream that is some cases outstrips the original company. I would say at least 95% of the attempts to do this fail though so don't take it as granted.

I don't understand why this causes so much confusion and conversation. If you are working with others then a force push is off the table. The only time you force push is to fix a catastrophic error. Forget it exists. When working locally please rebase LOCALLY and clean up your commits before pushing an MR. No one wants to see fix 1, fix 3, rollback etc. Plus team environments usually have strict commit templates linked to Jira tasks etc. Rebase -i is your friend. I think people for some reason struggle to understand their local git repo versus the actual shared git repo everyone is using.

Developers confuse technical stack (the how) with the why (what business value is my solution delivering).

There are just more choices today. You don't query for the latest stack and work back words.

Are you building a dog house or a skyscraper? If its a dog house use vanilla js or whatever works. If your building a skyscraper then use a react stack or something that has wide developer support since now your working on a large team on a large web application and the requirements have changed.

Server side rendering for example is to solve the issue of first load but is that actually something the business must have? It also adds CPU processing to your back end and more complexity. Is the trade off worth it for your business?

The reason the business pays us money is so we learn the trade offs and make the correct technical decisions, not that we blindly grab the new hot.

Most hacker news links I see like this is a developer confusing their world (small shop, internal IT dev, large shop, enterprise development, contract work for medium size business, FANG company etc) with the whole world and think there is one solution that applies to all worlds.

I really enjoyed Common-Sense-Guide-Structures-Algorithms https://www.amazon.com/Common-Sense-Guide-Structures-Algorit...

Since it was more pragmatic and less math driven.

Read Code Complete first then read Clean Code with a healthy dash of skepticism and do not follow it blindly. I still think Clean Code is a great book but does fall into "the one true way" and dogmatism.

This is the advice I give junior developers. I explain that Clean Code turns everything up to 11 and can make the code less readable then more if followed without thought.

The iron rule is the person doing the work also supplies the estimates, which are the only ones with any chance of getting them right. This article seems the developers have not been properly trained on how to give accurate estimates.

https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

We just ran into this CORS Same-Site cookie issue and it is going to become much more common. If the original author expanded to include the Same-Site rules as it applies to cookies it would be great!

"If someone wants to learn something you cannot stop them and if someone does not want to learn something you cannot force them"

THIS! Not having a defined Date format has caused so much confusion with consumers of our API since every json API might have a different ISO date format (or some homegrown madness).

In Java/C# land exceptions are EXPENSIVE. Like magnatudes more expensive. You have to build a full stack trace etc. Removing places in the code where it is "Throwing exceptions for non exceptional circumstances" has a dramatic performance increase benefit.

While humerous this comment is way to verbose. We prefer the following template >

Issue: What is the problem we are attempting to fix

Cause: What is the root cause of the issue, since with bug reports this is usually much different then the random musings of the reporter

Fix: How does the commit address the cause.

Each of these should be 1-3 brief lines

It is a good chapter to read to see their methodology even if you don't agree with the results. For example, comparing stricter/easier gun laws and prison times in different cities and not finding a correlation to the drop in violence since it was across the board.

Freakonomics makes a case the drop in crime is directly correlated with the passing of Roe VS Wade and the legalization of abortion. This led to the 18 year later drop in unwanted male children now adults. Very interesting read on a very explosive topic :)

Work on a code base with 40 plus developers and 30-40 commits a day. Having a clean commit history is a must versus "test commit", "fixed that thing", "added" etc.

For a web server under high load, exceptions are extremely expensive to build the stack frame as mentioned below. The rule of thumb is to reserve Exceptions for Exceptional Circumstances (oom, unable to connect to db etc) and to use a pattern like in this article for un-exceptional exceptions such as required field validation errors. Having done this clean up a few times, it makes a huge difference.

night owls or just owls. Cuz if they were actual owls that would be awesome.

They asked to use the restroom and never came back. True story.

Also if your trying to make that drastic a switch, are you willing to take a paycut? Just because someone has 15 years kernal experience does not mean they deserve the same pay for mobile (or visa versa).

If you come into the interview and say "I am a kernal developer but I want to work on mobile" and you show us a working mobile app you developed on your own, we would consider it. If you come in and say "I am a kernal developer and I want you to take a chance and pay for me to get up to speed on mobile development" that is a harder sell. If you ran a business, would you choose that person or the person who comes in with actual mobile experience and hits the ground running. I sense a lot of hostility in this thread from people who have never been on the other side of the desk. Put yourself in the shoes of someone who interviews a ton of people, and where hiring the wrong person is much worse then not hiring the right person.

Number 1: I think this is due to specializing in Ruby on Rails which is falling out of favor? Or your city location? I know in my location the average job hunt is 2 weeks.

Number 2: As someone that interviews people alot, this is cuz MANY people who apply CANNOT code, no matter what their resume says. We have had people leave and never come back during our console app on site test (read in a text file and print out its contents with some minor formatting). This is resumes with 10 years plus experience in the language supposedly. And the computer has whatever IDE they prefer and full internet access!

Number 3: I agree that CS type questions are pointless unless you are doing stuff like that on the job. We have stopped using those.

Number 4: We now require an onsite 2 hour code project (designed to fit in that time frame)

Number 5: True

Number 6: We use headhunters to weed people out but that is about it. For one position the head hunter roughly run 15 people applying for each 1 possible person to pass to us for the next step. Again, most fail a mind boggling simple phone interview process for people who claim 10 plus years experience in coding. Not knowing what the static keyword means in C# when they say they are skilled in C# for instance.

Number 7: Don't have an opinion on this

Number 8: Again this seems to be your physical location. At ours there is roughly 3 open positions for each matching person.

Number 9: Our company does not discriminate on age and are desperate for qualified people with experience. Many times a candidate regardless of age is stuck in one tech (winforms, MVC, Ruby on Rails (:P)) and we more discrimate on someone who is not showing growth in their tech skillset. For example, are you learning the basics of a cloud stack such as AWS/Google/Azure?

At the end of the interview, I would recommend asking "are there any concerns or issues you would have with hiring me for this position?" and LISTEN to their feedback. I am sure there are some bad companies but for the most part it feels like you are not interviewing well for whatever reason. Maybe you are coming off as defensive or hostile when questioned? I would also reach back to the company and ask why they did not choose you. Most companies are way to busy to tell each person why they were passed over, but if you show an interest they will usually respond.

Anyway good post and good luck to you!

Roger Ebert said it was due to a Film Critic seeing 2-3 movies a Day. If you are seeing that many movies, you start to yearn for something different and challanging. If you see at most 1-3 movies a month on a good month, you tend to be ok with "just" entertaining movies. Also critics like to see movies that move the artform forward in some way. So while Bright on Netflix is a very servicable by the numbers movie, it is not really doing anything outside the box.

https://www.youtube.com/watch?v=A-xnjDevAzE . Fakes are indeed a part and fear of the market. Note the cards have specific tests that weed most out, due to the amount of effort needed. The light test and spring test for example.

The Git GUI that ships with git is very good. It also shows how Git thinks (workspace/staging/commit) that most other gui's struggle with (they try to make it look more like a SVN workflow). For diffs and blame I use TortioseGit. I also extensively use the CLI for most branch actions.

We had huge problems with Java and Lambda start up times. I would strongly recommend python/nodejs or maybe Go. For whatever reason .Net core was still slower but not Java holy crap slow.

There is a world of difference between a Micro-ORM such as Dapper and a bloated mess of an ORM like Entity Framework. They are not even close to the same thing.

My wife's comment was "I can get all these ingredients at the local super market and there is a lot of prep work". If Blue apron or a like service had all the food ready to go into the oven/microwave we would of stuck with it. Since she still had to do all the chopping and prepping, it was a waste of time.

See also GWT if you are just hell bent on running Java in the browser. As one of our developers commented, 'it is webforms all over again'. Also see https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

For legacy apps or if your back end is Java and you need to share code, GWT and this concept is a good solution. If you are just trying to avoid learning JavaScript/CSS this will leave you very unhappy.

I would also mention "Emergent Design" along with KISS and YAGNI. Do not start your code base with a collection of design patterns. This is the usual cause of a complete over designed mess. Instead as the code grows look for the patterns to emerge and then apply them.

detrimental?