Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
gashmol
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
31.
▲
by
gashmol
3y ago
I figured if you don't have a job or are working in a bad environment everything else is negligble.
32.
▲
by
gashmol
3y ago
How often does it actually happen?
33.
▲
by
gashmol
3y ago
Where does it hurt more, in new dev or maintenance?
34.
▲
Ask HN: What are the top pains of software developers?
16 points
by
gashmol
3y ago
|
42 comments
35.
▲
by
gashmol
3y ago
Managers.
36.
▲
Ask HN: Why software such as Salesforce and Jira are successful marketwise?
4 points
by
gashmol
3y ago
|
3 comments
37.
▲
by
gashmol
3y ago
Pure Top down only works for small problems or problems you already know how to solve. Its main issue is that you don't know whether the solution is correct until you reach the bottom. Structured Design, which is a quasi top down metho
38.
▲
by
gashmol
4y ago
A chrome extension for showing a preview (summary and screenshot) of a link on hover. Android app for saving webpages for offline viewing.
39.
▲
Basecamp details 'obscene' $3.2M bill that caused it to quit the cloud
(theregister.com)
15 points
by
gashmol
4y ago
|
4 comments
40.
▲
by
gashmol
4y ago
Software Estimation: Demystifying the Black Art is a good book on the subject.
41.
▲
by
gashmol
4y ago
I think there are other ethical issues you should be worried about before this one.
42.
▲
by
gashmol
4y ago
It has one chapter that sumarizes refactorings. Enterprise patterns or design patterns in general are about software design. IMHO design patters are the worst way to learn about design in software.
43.
▲
by
gashmol
4y ago
I would skip Uncle Bob and Marting Fowler's books and just read Code Complete. It has everything you might want to know about coding and then some.
44.
▲
The Elephant in the Event Loop
(gashamola.com)
1 points
by
gashmol
5y ago
|
0 comments
45.
▲
by
gashmol
5y ago
High Output Management - for general management issues. Software Project Survival Guide - for software specific issues. (Don't be discourged by all the documents it discusses.)
46.
▲
by
gashmol
5y ago
Thanks, I'll check it up.
47.
▲
by
gashmol
5y ago
Which book would you suggest to read first?
48.
▲
The Jerusalem Syndrome
(en.wikipedia.org)
3 points
by
gashmol
5y ago
|
0 comments
49.
▲
Ask HN: Any Good Books on Marketing?
2 points
by
gashmol
5y ago
|
6 comments
50.
▲
by
gashmol
5y ago
As a form of testing I think there are two main reasons: 1. If we need to push this feature now, some say, reliability and future modifiability only get in the way. Under pressure people tend to focus on mere survival. 2. Developers don
51.
▲
by
gashmol
5y ago
It reminds me of The Matrix. The machines tried at first to make humans always happy in the virtual world they've created. They did that not out of care for humans, but in order that they could peacefully harvest energy from the oblivi
52.
▲
by
gashmol
5y ago
> Most people, esp. in the US especially and in Western Europe in general fake happiness. esp in public. With true friends less. I think it's largely true. Interstingly enough there are parts of the world where faking unhappiness is
53.
▲
by
gashmol
5y ago
50% of the time talking sounds like a nightmare. I don't think you can build anything nontrivial if you get interrupted all the time.
54.
▲
by
gashmol
5y ago
High Output Management covers alot of it and then some.
55.
▲
by
gashmol
5y ago
It sounds that you lean heavily on OOP methods. I find OOP to be weak in the design stage. It does help later to simplify the code. But, only after you find out where the actual objects are. I prefer ERD for any modeling I might need in the
56.
▲
by
gashmol
5y ago
What kinds of sketches do you draw? Try to write pseudocode for the critical parts so you can test your design before you write code.
57.
▲
by
gashmol
5y ago
I start with high level design to have a chance to get the required performance, scalability and other targets. Then, it depends on the particular problems I encounter. Sometimes I'll do another phase of design, other times I'll
58.
▲
by
gashmol
5y ago
> I basically end up writing pretty much anything twice That's how top down usually works. It's good for problems you've already solved before.
59.
▲
by
gashmol
5y ago
You can't have it all. You may achieve simplicity but it's not easy. Rails has most of what you need for a web app, and its ecosystem has many complementary subsystems and libraries. So, it's very easy to develop something fa
60.
▲
by
gashmol
5y ago
Overworking the prototype is a real risk, that's why experienced devs should work on it. Sometimes its enough to do it on paper. Whats important is to capture the product in an objective form as quickly as possible and then show it to
More ›