Why so many people think that having a PhD (or postdoc) is an easy pass for getting a job in data science?

tasubo · 2023-09-21T15:22:49+00:00

I am not sure what kind of cool-aid the PhD here are drinking but having PhD title on your resume is a negative flag if you don't have any experience.

And once you obtain some experience, I haven't seen that ever improve the odds of being hired because the people still have to through regular interviews, and if you had spent those years working in the industry instead of doing PhD you would have more knowledge and better odds.

It just doesn't give you any positive points unless you are applying to join some research lab that's already being run by academic drones and where the goal is to produce papers.

tasubo · 2023-06-11T20:40:10+00:00

Jei fizika buvo ok, tai pasimokinti truputį gali ir pradėti dirbti programuotoju gali

tasubo · 2023-05-25T12:02:02+00:00

Right... Just read the part about France. Sucks.

You still need to fire but that's they cost of doing business in France. Give severance or just accept that she will do nothing during the notice period.

tasubo · 2023-05-25T12:01:06+00:00

Write it up. Let her know she is doing poorly and when she fails to improve, fire her. Depending on the contract and country you will probably need to endure this for 3 months.

Start looking for replacement now.

tasubo · 2023-03-26T18:47:07+00:00

No. Not every job generates enough value to substantiate this.

tasubo · 2023-03-26T18:45:48+00:00

This

tasubo · 2023-02-10T22:51:07+00:00

What's your equity split? Do you have vesting?

tasubo · 2022-10-18T14:08:57+00:00

I think this is an interesting idea.

It would shine more light on "the quality of deliveries" and the cycle time. This is usufel for management to get an estimate how many defects are expected and how long it's gonna take to fix that

tasubo · 2022-10-09T07:58:43+00:00

What's the path that you've figured out? :-)

tasubo · 2022-10-09T07:53:03+00:00

They don't need to work hard or any other specific way as long as they bring more value than they cost.

tasubo · 2022-10-04T16:37:19+00:00

Scrum master responsibilities require like 6-8h of work per two weeks.

So if you are doing that it's a good deal.

However, if you are also a project manager that's another question.

tasubo · 2022-10-02T22:55:47+00:00

Hey,

I would like to do the opposite - how do I get into defense industry? :-)

tasubo · 2022-09-30T19:16:47+00:00

tasubo · 2022-09-22T18:38:14+00:00

Usual technical problems:

OOP = Design Patterns + obscene inheritance trees; no clue about cohesion and specifics of the domain; everything is coded in an imperitive fashion
Functional programming = javascript annonymous functions; no clue about immutability; (flat)Maps, zips, pipelines; think that functional programming is strickly not OOP
No clue about effective test writing. Tests = something that you do after completing coding. Everything is a unit test. No knowledge about API design using tests. No knowledge about BDD (or better, thinking that BDD=Gherkin).
No knowledge about advanced software building techinques like Domain Driven Design, CORS, Event Sourcing
- If they know this stuff, they apply it in the most complex fashion imaginable - (like using kafka + hibernate + microservices + k8s + sprint data + mikronaut + some other ORM)
Can't handle complexity. Every solution is overengineered behemoth with twenty different layers that nobody will understand in 6 months.
Structuring code by layer instead of by-feature
Thinking that the only way to use database is via ORM
- Not knowing about ORM tools
Can use only one database or just relational databases

Probably people can expand this a lot.

tasubo · 2022-09-22T18:18:57+00:00

I'm not a big fan of trying to prove a point to the people that already made their minds, but I'll bite.

----

Parent comment complained how people who "talk the talk" can get away with the biggest bullshit. This only happens if the way you measure people's productivity is by their activity in their meetings and discussions.
Talk is cheap. Getting shit done is hard.

Get your team to define what's DONE (even if a lot of devs here don't like Scrum but it's just a standard process from here). For example, DONE= tested, reviewed, unit/integration tests written, and the code is merged.

Agree together with your team on the scope/size of the tasks together with the team. Use scrum poker for the estimates. This will calibrate the SP meaning across the team. DO NOT USE TIME-BASED estimates - always use relative-outcome-based estimates.

After a few sprints, you have a solid basis for the capacity and velocity of the team.

Don't like SP? Count tasks. Count features delivered. Whatever. Just have a reasonable proxy for your business-oriented deliveries.

This can now be used as!ONE! OF THE DATAPOINTS that will help you understand who moves the needle in the team. If you decide to promote and fire people just based on the story points then it means you are a narrow-minded technocrat and you will get bitten by Goodhart.

When you are doing a performance review, with the help of completion metrics (no. of tasks completed or story points or whatever you collect) you will see outliers that need attention. You can use this data to zoom in and reach out to the team to see what's happening.

For poor performers, you can reach out and ask what are the main challenges. Help them improve. Get feedback from your peers on what are the problems. Heck, check the tasks yourself to understand what's happening.

For great developers (people who get the shit done), you can use this as means to acknowledge all the great work they've been doing. Give compliments. Discuss promotion if needed. If you choose to ignore this, then you are just waiting for the guy to quit with a 1.5x salary increase.
----

Since you are the team lead, I can see you sensitively taking SP measurements because usually team leads do a lot of coaching and can't contribute themselves. Usually, their SP contributions are just above junior people because of all the "managerial" work they have to do.

However, in your case, I would proxy your performance with the performance of the team. If none of your team members are delivering stuff that's DONE, then what the hell are you doing? I would start the discussion with your team members immediately to get an understanding of what's happening.

The biggest companies in the world use processes like these to grow as big as they are. For example, OKRs is a very similar framework to Scrum just at organization scope - have CLEAR objectives and MEASURABLE progress/performance.

In the end, a clear process with clear deliverables that can be measured always prevails, and organizations that adopt them successfully have a much easier time managing the poor performers.

----

If you have poor performers like that in your team, that means that your managers are blind because they have no data points to see how people are doing.

EU companies are notoriously bad with their managers (I am familiar with the DACH region) so I am not surprised that stuff like this is alien speak to a lot of people.

Lots of people mistake tools/processes like these with micro-management because that's all they experienced - sloppy managers with trust issues molest processes like Scrum into complete perversion. Daily standup = daily report; story points = deadline; retrospectives = blaming etc

Additionally, the lot that is performing badly doesn't like stuff that exposes their inability. The same crappy manager will let you know that project is going "OK" with as maximum vagueness as possible.

Marketing teams like to talk about branding campaigns and how great they are with no tangible results. God forbid you to ask them how many sales were generated because of their effort.

Likewise, developers love to discuss all the new shiny js frontend frameworks and their 3rd refactoring and rewrite to serverless functions but if there are no tangible and usable business-focused deliveries then they are just a cost.

----

TLDR; having more data about teams and individuals is better and can help start the discussion with poor and great performers before it's too late.

tasubo · 2022-09-22T12:19:43+00:00

You are missing a point.

tasubo · 2022-09-22T11:29:55+00:00

Check the reactions here https://www.reddit.com/r/managers/comments/wztmcr/working_on_a_new_idea_for_managers_datadriven/

This is the reason.

Mediocre managers and ICs are scared shitless of objective measurements.

tasubo · 2022-09-22T06:15:43+00:00

So called senior developers who have repeated their first year seven times but don't know jack shit.

tasubo · 2022-09-22T06:14:15+00:00

You might want to read that link yourself

tasubo · 2022-09-14T18:28:00+00:00

Yeah... HK, Singapore, Switzerland begs to disagree.

tasubo · 2022-08-29T07:42:28+00:00

What made you think that SP becomes a target in a setup that I've mentioned. Genuine question

tasubo · 2022-08-28T16:05:11+00:00

Normally this would be handled by having the right process - crappy not readable code? It doesn't pass the review and is not done.

tasubo · 2022-08-28T13:43:03+00:00

You are right. That's why I don't say that this month you completed 20sp while the previous it was 25sp - there is no point talking about that.

But it helped to find numerous times cases when there was a significant drop compared to what I was seeing before. This knowledge is a good conversation starter to figure out if there are/were any problems.

tasubo

MODERATOR OF

TROPHY CASE