If you've more than a couple of years of experience in IT, you probably have stumbled upon the following quote:
There are only two hard things in...
For further actions, you may consider blocking this person and/or reporting abuse
I just graduated and started my first job as a developer. The thought of having to provide accurate estimates for my work seems really intimidating 😬
Multiply your own estimates by Pi (3.14). It ensures you always overdeliver and underpromise. People are only angry if you promise something you cannot keep. If you multiple your own estimates by Pi, you're 95% likely of being able to deliver below expectations ... ;)
I'd also add that it's much easier to estimate small things than big things.
If your estimate is longer than 5 days, then break it up into parts until all your estimates are under 5 days.
Yet another tip: design your UI first, then make your estimate. Estimates become a LOT more certain once you've defined the UI (look up cone of uncertainty for a graphical explanation).
This isn't entirely true for many projects. Developer management doesn't get angry if you over-estimate your work, sure, especially in a dysfunctional company where the development team doesn't care about the business side. Everybody who interacts with the outside world, though, and might need things done to beat competition or have releases available for key events get extremely angry when told to put off their big announcements, and then find out that their original deadline would have worked. Or worse, it means that projects get cancelled, because yours will take too long to help the overall strategy.
Estimating requires experience, lots of it, and even then, the gap between the estimates and the final time can be huge.
Asking a freshly-graduated teammate to estimate is a huge failure on the part of the organization. I'd advise to push back on this. My personal feeling is that it's a sign of a dysfunctional organization and it's just the tip of the iceberg.
I've found it enough of a mess at every company that I wrote a post describing what I've done for fairly solid estimates.
How Long Will That Project Take?
John Colagioia (he/him) ・ Jan 28 '21 ・ 10 min read
It takes time itself, but I find that it's worth it to consistently hit the target.
OMG timezones are soooooo painful! Even if you store all your datetimes in UTC a looot of work is needed to accurately display data to users around the world.
Great article! There are really a lot of hard things in CS.
Though you alluded to it, read-after-write and write-after-write are incredibly difficult at nearly any scale of concurrency. Do you use locking, where even if you have a great acquisition-is-initialization sort of scheme, it gets bad if the locks are held too long? Or do you reconcile after the fact, potentially subjecting users to difference merging? Difference merging already causes angst in programmers, I can't imagine asking normal users to do it.
On the subject of proof languages, I'm extremely pessimistic. I feel like the only thing Prolog proves is that declarative languages can't really exist: writing correct (much less efficient) Prolog code means writing it against the behavior of the evaluation engine. That's not really any different from imperative programming. I never learned Coq, mostly because Prolog left such a bad taste in my mouth. Likewise with Idris, I wanted to like it, but could never find anything that actually made it better than Haskell.
The overall problem with bugs is, apart from hardware exceptions like invalid pointer dereference and integer divide by zero, a "bug" is software doing something other than what you intended. The challenge, then, is coming up with a formal language of intent—which is what programming languages already are. Proofs can only ever be a stripped-down analog of the language you're actually using, but once you try to scale proof specification up, it becomes just as error-prone. Or maybe more error-prone, since proof systems are themselves quite obtuse and complicated.
"It depends" what you value most:
Back to the CAP theorem. There's no correct answer, you need to choose. And the choice depends on your business requirements. Nowadays, the trend is toward Availability but I'm pretty sure that banks will frown upon that and value Consistency instead.
Compilers design and optmization are very hard things in computer science
Only if you believe so. We've got an execution runtime, on top of which we built our own programming language called Hyperlambda - And it's execution runtime is 10 lines of code. For the record, it's neither compiled nor interpreted, so arguably you're correct still ... ;)
It would be nice if cache invalidation and naming things were the hardest things I had to do :) Lately the hardest thing for me has been release coordination. Not really "computer science" but I don't think cache invalidation or naming things really are either.
That's true.
It would be nice if cache invalidation and naming things were the hardest things I had to do :)
😂
github.com/ligurio/practical-fm