Hacker News new | past | comments | ask | show | jobs | submit | frogcoder's comments login

Working from 9 to 9 six days a week


I've been organizing my python projects starting with package folders.

Say I name my package "foo", foo is the top level folder for the source code. Inside foo there is a "main.py" file as the project's start point, and other various modules, let's have one called "module1.py". Now, add another package under "foo", the obvious example name here would be "bar", and add another module under "bar" called "module2.py".

The project structure looks like this:

  - foo/
    |- main.py
    |- module1.py
    |- bar/
       |- module2.py
To reference "module1.py" in "module2.py", just write

  import foo.module1
To reference "module2.py" in "main.py", do as follows

  import foo.bar.module2
There is no problem importing from any level.

To start the program from command line, enter:

python -m foo.main


anecdotally I can support that `python -m x.py` is a better way to go than `python x.py`. Somewhere I found the tip that writing `python3.9 -m pip install $pkg` is a more reliable way to run `pip` for a specific version.

It should not be so complicated.


Well, again it depends on the culture. Some boss wouldn't take any disagreement from subordinates well. No matter what the result looks like, if the boss doesn't declare the project failed, than that's not a failure. Even if it failed, the subordinate takes the blame, it's less serious than bringing up issues early because the boss's order is faithfully carried through to the end.


It wasn't even about a disagreement.

If was like "Get a mop, a bucket in the storeroom, pour in a cup of sugarsoap into the bucket and fill up with water then wash the floors". They washed the floors even though they couldn't find the sugarsoap because by accident they god sent sugar and soap instead, so they put that in, perfectly understanding what sugarsoap is and why sugar and soap won't replace it.


I was expecting a sad ending after six years. Glad it turns out well.


This service is lacking a major feature and too complicated!

Almost half of the time, I need to know if a number is even. Why doesn't it provide an end point for that?! Don't even tell me about the 409 status code. Am I suppose to know it's an even number when it returns an odd number to me? I only recognize status code 200, all other are errors, don't make this so complicated!


Start with something you can handle. Which language doesn't really matter but keep in mind that are so many possibilities. When you are comfortable with your first language, try some other, preferably with a different paradigm. It's totally fine using one language for development most of the time, just remember there are so many ways to accomplish one task.

The age does not matter as long as you can sit down and code. You don't see many old people doing programming because it's simply not many there. Computing is relatively new. It's obvious most people entering this field would be young, older people might require a change of career hence less incentive.


My Pa just retired. 30+ years of coding. Most older people aren't coding because they get promoted out of it. Some stay with it, because they love the puzzles.

Here's what I say.. If you can fix a car you can debug code. You take all the info you can get and you make guesses, then you narrow it down. Writing new code is about the same. Find something you want to do, and poke until you get it. As time goes on you get faster.

Important bit of coding as a job though. You are always falling behind. Tech moves so fast, there's always something to learn. It's a blessing and curse. Sometimes it feels like too much, and other times it's just the best thing ever.


Disclaimer: I was never at any position close to like Sr. Director at a fortune 100 tech giant, maybe your company is different.

I use to act as if I own a large stake of the company I worked for, regretting it much later when I realized I was doing too much and knowing too little.

I was just kidding myself pretending as an owner of the company therefore investing too much emotion and work into it. Why would I pretend something that is not true? It's not like fake it until you make it thing.

I do not know how much you know about your company, but I was an outsider that knew nothing about the inner workings and secrets about it. I thought I knew, that's the kidding myself part.

Unless you are a real owner, you are just a cog in a machine. If you perform well, you will be rewarded well as a cog in a machine not as an owner. Most decisions you make would not affect the overall situation. Just do your job well and try to spend time with something else you care after work, not something you have no control of.


Guess the author thinks Confucianism is bullshit (fart). I APPROVE!

The sample image of the first feature is Confucianism surrounded by the fart character. The feature highlight only one found entry per line. That is what you get when you search for fart.


Most of newly graduates of any subject don't know much about real world jobs. You are just one of many, but you care to ask about this on HN, that's something.

And a warm welcome to this imposter syndrome help group, we are always afraid of missing out on some tech. Accept it, everyone is missing out on most of the tech.

When I was studying CS in college, I always wondered why the classes don't teach us about the hot Windows programming thing. All we did were tiny console C programs. I realized that very late, CS classes are meant to let you know about the fundamentals. You probably won't use these skills directly at work, but you will have ideas about how the languages and systems work internally. That pays in the long run.

Just go explore and make mistakes, you will be alright.


> All we did were tiny console C programs. I realized that very late, CS classes are meant to let you know about the fundamentals. You probably won't use these skills directly at work, but you will have ideas about how the languages and systems work internally. That pays in the long run.

At one point you realize, when you remove all the boilerplate, every piece of software is fundamentally just a "tiny console C program". All IPC and networking is isomorphic to reading stuff from stdin and writing to stdout. And when you ignore IPC, all you're left with is just pure algorithms.

Leetcode (and the likes) always made sense to me. It's measuring how well you can solve the fundamental problems, not how well you can fill out vendor-specific bureaucratic forms.


I think that you're missing the linking element of software units. It can be very intimidating, particularly from an outside view.

I have been writing C for years and I can tell you in a second if you are accidentally dereffing the stack or not doing a bounds check. Yet, I still barely know my way around CMake! It's daunting, and I haven't worked on any enterprise scale C projects, hence I have no reason to learn how to properly separate, and later integrate, my software components.


I agree, but even modularity is just an implementation detail, rising from the finiteness of human work capacity and computer resources. Algorithmic solution to the problem is the same, whether it is implemented in a single implementation-specific C file or a cross-platform multi-repo project. Also, it is (IMHO) much easier to learn engineering principles, than how to solve algorithmic problems. The latter is akin to solving mathematical problems, which require finding a problem-specific needle of knowledge in the haystack of mathematics.


I still write console programs all the time. But I haven't programmed for Windows in over a decade.


It's also helpful to realize that you "stand on the shoulders of giants".


Funny, I think the walrus operator makes code cleaner and easier to understand.

Many of my code were like this:

    foo = one_or_none()
    if foo:
        do_stuff(foo)
Now I have the following:

    if foo := one_or_none():
        do_stuff(foo)
This kind of code happens quite frequently, looks nicer with walrus operator to me.


I haven't yet fully adjusted to the walrus operator, but to me the choice would depend on what happens _after_ the "if" statement.

In both cases, "foo" continues to exist after the "if" even though the second example makes it look like "foo" is scoped to the "if".

So to my eye, the following would look super weird (assume do_more_stuff can take None):

    if foo := one_or_none():
        do_stuff(foo)
    do_more_stuff(foo)
whereas the following would look fine:

    foo = one_or_none()
    if foo:
        do_stuff(foo)
    do_more_stuff(foo)


Honestly, for this specific case, I prefer one_or_none() to return an iterable with zero or one items, and then just doing:

  for foo in one_or_none():
    do_stuff(foo)
If you don't control one_or_none, but it returns an Optional, you can wrap it with something like:

  def optional_to_tuple(opt_val: Optional[T]) -> Tuple[]|Tuple[T]:
    return (opt_val,) if opt_val is not None else ()


Would have been more Pythonic as:

    if one_or_none() as foo:
        do_stuff(foo)


I didn't recognize this use of "as" as valid Python, but tried it in 3.9 just to be sure. Got a syntax error (as expected).

I am not fully up to speed with 3.10, but quickly checked the docs and it doesn't appear to have been added in 3.10 either.

Let me know if I'm missing something.


Oh, "would have" meaning python-dev chose a different spelling. Not, as in it would-have been better if the example was written this way.


Oh, I see now. Thanks for the clarification.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: