Everyday i used to spend an hour in the morning reading emails.

Until i made a script that reads all mails, parses to urgent/priorities/meetings etc. Then shows me a dashboard of everything. 1 hr turned to 20mins max.

Then i made a chatbot out of it and now i just talk to it everytime and gives me the rundown.

Gave me so much time to code instead of reading fucking emails.

Are you a C# developer, and do you want to contribute to the devRant public api C# variant. This is your chance!

Fork the code and help the community project.

https://github.com/WichardRiezebos/...

If Carpenters Were Hired Like Programmers
.....

Interviewer: So, you're a carpenter, are you?

Carpenter: That's right, that's what I do.

Interviewer: How long have you been doing it?
Carpenter: Ten years.

Interviewer: Great, that's good. Now, I have a few technical questions to ask you to see if you're a fit for our team. OK?
Carpenter: Sure, that'd be fine.

Interviewer: First of all, we're working in a subdivision building a lot of brown houses. Have you built a lot of brown houses before?
Carpenter: Well, I'm a carpenter, so I build houses, and people pretty much paint them the way they want.

Interviewer: Yes, I understand that, but can you give me an idea of how much experience you have with brown? Roughly.
Carpenter: Gosh, I really don't know. Once they're built I don't care what color they get painted. Maybe six months?

Interviewer: Six months? Well, we were looking for someone with a lot more brown experience, but let me ask you some more questions.
Carpenter: Well, OK, but paint is paint, you know.

Interviewer: Yes, well. What about walnut?
Carpenter: What about it?

Interviewer: Have you worked much with walnut?
Carpenter: Sure, walnut, pine, oak, mahogony -- you name it.

Interviewer: But how many years of walnut do you have?
Carpenter: Gosh, I really don't know -- was I supposed to be counting the walnut?

Interviewer: Well, estimate for me.
Carpenter: OK, I'd say I have a year and a half of walnut.

Interviewer: Would you say you're an entry level walnut guy or a walnut guru?
Carpenter: A walnut guru? What's a walnut guru? Sure, I've used walnut.

Interviewer: But you're not a walnut guru?
Carpenter: Well, I'm a carpenter, so I've worked with all kinds of wood, you know, and there are some differences, but I think if you're a good carpenter ...

Interviewer: Yes, yes, but we're using Walnut, is that OK?

ADVERTISEMENT

Programmer T-shirt

Buy it now!
Only available till Monday!

Carpenter: Walnut is fine! Whatever you want. I'm a carpenter.

Interviewer: What about black walnut?
Carpenter: What about it?

Interviewer: Well we've had some walnut carpenters in here, but come to find out they weren't black walnut carpenters. Do you have black walnut experience?
Carpenter: Sure, a little. It'd be good to have more for my resume, I suppose.

Interviewer: OK. Hang on let me check off the box...
Carpenter: Go right ahead.

Interviewer: OK, one more thing for today. We're using Rock 5.1 to bang nails with. Have you used Rock 5.1?
Carpenter: [Turning white...] Well, I know a lot of carpenters are starting to use rocks to bang nails with since Craftsman bought a quarry, but you know, to be honest I've had more luck with my nailgun. Or a hammer, for that matter. I find I hit my fingers too much with the rock, and my other hand hurts because the rock is so big.

Interviewer: But other companies are using rocks. Are you saying rocks don't work?
Carpenter: No, I'm not saying rocks don't work, exactly, it's just that I think nail guns work better.

Interviewer: Well, our architects have all started using rocks, and they like it.
Carpenter: Well, sure they do, but I bang nails all day, and -- well, look, I need the work, so I'm definitely willing to use rocks if you want. I try to keep an open mind.

Interviewer: OK, well we have a few other candidates we're looking at, so we'll let you know.
Carpenter: Well, thanks for your time. I enjoyed meeting you.

NEXT DAY:

Ring...

Interviewer: Hello?
Carpenter: Hello. Remember me, I'm the carpenter you interviewed for the black walnut job. Just wanted to touch base to see if you've made a decision.

Interviewer: Actually, we have. We liked your experience overall, but we decided to go with someone who has done a lot of work with brown.
Carpenter: Really, is that it? So I lost the job because I didn't have enough brown?

Interviewer: Well, it was partly that, but partly we got the other fellow a lot cheaper.
Carpenter: Really -- how much experience does he have?

Interviewer: Well, he's not really a carpenter, he's a car salesman -- but he's sold a lot of brown cars and he's worked with walnut interiors.
Carpenter: [click]

Tired of chasing an elusive architecture and finding good community that helps promote it. Basically:

- Not CRUD
- Not MVC
- More like CQRS; commands and queries represent use cases
- Event Sourced; event log is source of truth, everything else is a cached projection
- Functional Domain Design; not DDD; focus on immutability and simplicity
- Functional in general; less OO
- More focus on domain concepts rather than tech concepts
- Domain can be used through CLI, API, or SDK
- UI is just another client to the API
- Authorization is ABAC, graph-based access control

I'm looking for a fucking unicorn.

!rant

After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:

1) Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.

2) Working independently is a must. It's okay to ask questions, but ask sparingly. Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc..)

3) Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.

4) Ask for peer reviews and LISTEN to the critique. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Peer reviews are win-win-win.

5) When in doubt, do NOT BS your way out. Refer to someone who knows, or offer to get back to them. Often times, persons other than engineers will take what you said as gospel. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.

6) Slow down in order to speed up. Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. Rushing to complete, even for senior engineers, usually means less-than-ideal code that somebody will have to maintain.

7) Write documentation, always! Even if your company doesn't take documentation seriously, other engineers will remember how well documented your code is, and they will appreciate you for it/think of you next time that sweet job opens up.

8) Good code is important, but good impressions are better. I have code that is the most embarrassing crap ever still in production to this day. People don't think of me as "that shitty developer who wrote that ugly ass code that one time a decade ago," They think of me as "that developer who was fun to work with and busted his ass." Because of that, I've never been unemployed for more than a day. It's critical to have a good network and good references.

9) Don't shy away from the unknown. It's easy to hope somebody else picks up that task that you don't understand, but you wont learn it if they do. The daunting, unknown tasks are the most rewarding to complete (and trust me, other devs will notice.)

10) Learning is up to you. I can't tell you the number of engineers I passed on hiring because their answer to what they know about PHP7 was: "Nothing. I haven't learned it yet because my current company is still using PHP5." This is YOUR craft. It's not up to your employer to keep you relevant in the job market, it's up to YOU. You don't always need to be a pro at the latest and greatest, but at least read the changelog. Stay abreast of current technology, security threats, etc...

These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!